OPIC 



Office de la propri£t£ 
intbllectuelle du canada 




CI PO 



& Canadian Intellectual 
Property Office 



(72) GARNER, CHRIS, US 
(72) MUNSON, SYLVIA, US 
(72) CURFMAN, TIM, US 
(72)HUNG,NGO,US 
(72) SYKES, STEVE, US 
(72) WOOD, HEATHER, US 
(72) COHRON, JOHN, US 
(71) ALTRA SOFTWARE SERVICES, INC., US 
(51)IntCl. 7 G06F 17/60 
(30) 1999/12/16 (60/172,361) US 

(54) GESTION EN LIGNE DE LA LIVRAISON DE PRODUITS 
(54) ON-LINE MANAGEMENT OF PRODUCT DELIVERY 



(i2)(i9)(CA) Demande-Application 

(21) (Al) 2,328,595 

(22)2000/12/18 
(43)2001/06/16 




HOLD/AUDIT 
DATABASE 
SERVER 
260 



HOLD/ 
AUDIT 
265 



R/W 



INTERNAL NETWORK 
► 



R/W 



tiuyMii iku 

DATABASE 
SERVER 
370 



SUBMITTED 
275 



R/W 



R/W 



HOLD/AUDfT 
INTERFACE 
DATABASE 
SERVER 
280 



F 
I 

R 

E 

VU| 

A 

L 

L 



WEB 
SERVER 
240 



WEB SITE 

I 

R 



255 



230-/ 



225 



SITE MANAGER 
HOLD/AUDIT/ED! 
SERVER 
245 



V 



R 
E 
W 
A 
L 

_L_ 
EDI SITE 



HOLD/AUDIT 
INTERFACE 

250 



N 
T 
E 
R 
N 
E 
T 




f 



THIN CLIENT 
205 

215 




THIN CLIENT 
205 



200 



r 



220 




HOLD/AUDrT/EDI 
CLIENT 
210 



(57) A computerized system for managing the scheduling and delivery of products. 



Industrie Canada Industry Canada 



CA 02328595 2000-12-18 

Docket No. 21702.52.05 

ON-LINE MANAGEMENT OF PRODUCT DELIVERY 
Abstract of the Disclosure 

A computerized system for managing the scheduling and delivery of 
products. 
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ON-LINE MANAGEMENT OF PRODUCT DELIVERY 

Cross-Reference To Related Applications 

The present application claims the benefit of the filing date of U.S. 
provisional patent application serial number 60/172,361, attorney docket 
5 number 21702.52, filed on December 16, 1999. 

Copyright Notice 

A portion of the disclosure of this patent document contains material 
that is subject to copyright protection. The copyright owner has no objection to 
the facsimile reproduction by anyone of the patent document or the patent 
10 disclosure, as it appears in the Patent and Trademark Office patent files or 
records, but otherwise reserves all copyright rights whatsoever. 

Background of the Invention 
This invention relates to automated scheduling and delivery of products 
and, more particularly, to computer implemented methods for interactive 
15 automated scheduling and delivery of products. 

The business-to-business purchase and sale of products has historically 
been primarily a phone/fax based activity. Such products are typically traded 
and brokered in industries such as, for example, paper, steel, trucking, food, 
energy, and flowers. Traders responsible for selling production, purchasing 
20 supplies, and procuring the physical delivery of such products typically 
communicate bid/ask prices by phone at one or more active market centers. 
Often these trades have been facilitated by phone-based Brokers, commissioned 
intermediaries that facilitate transactions between buyers and sellers, acting as 
agent not principal (i.e., Brokers do not take title or otherwise get involved in 
25 the delivery or payment aspects of the transaction.) 

In this traditional market, as trades were consummated, confirmations 
were then faxed, scheduling documentation was exchanged, and each trading 
partner used its own internal back-office systems to manage the trade through 
settlement. The majority of physical energy continues to be traded by this 
30 process today. However, such a complex transaction chain has proved to be an 
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extremely inefficient process which results in high transaction costs, missed 
trading opportunities, and complex operating procedures. 

The present invention is directed to overcoming or at least minimizing 
the limitations of the conventional processes for trading and delivering 
5 products. 

Summary of the Invention 

According to one aspect of the present invention, a computer 
implemented method of managing the delivery of products is provided that 
includes entering data relating to the delivery of the products using a user 

10 interface, interim storing some of the data in an intermediate database, 
submitting some of the data for processing by the system, and storing the 
submitted data in the intermediate database and a submitted database. 

According to another aspect of the present invention, a system for 
managin g the delivery of products is provided that includes means for entering 

15 data relating to the delivery of the products using a user interface, means for 
interim storing some of the data in an intermediate database, means for 
submitting some of the data for processing by the system, and means for storing 
the submitted data in the intermediate database and a submitted database. 
According to another aspect of the present invention, a computer 

20 program for managing the delivery of products is provided that includes 

instructions for entering data relating to the delivery of the products using a 
user interface, instructions for interim storing some of the data in an 
intermediate database, instructions for submitting some of the data for 
processing by the system, and instructions for storing the submitted data in the 

25 intermediate database and a submitted database. 

According to another aspect of the present invention, a computer 
implemented method for managing the scheduling and delivery of products is 
provided that includes providing an N-tiered database structure including 
interim stored and submitted scheduling and delivery data. 

30 According to another aspect of the present invention, a system for 

TTifinflgrmg the scheduling and delivery of products is provided that includes an 
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N-tiered database structure including interim stored and submitted scheduling 
and delivery data. 

According to another aspect of the present invention, a computer 
program is provided that includes instructions for providing an N-tiered 
5 database structure including interim stored and submitted scheduling and 
delivery data. 

According to another aspect of the present invention, a system for 
managing the delivery of products is provided that includes one or more thin 
clients adapted to enter data related to the delivery of the products, an 
10 intermediate database for storing interim saved data and submitted data 
related to the delivery of the products, a submitted database for storing 
submitted data related to the delivery of the products, and a host computer 
coupled to the thin clients, the intermediate database, and the submitted 
database adapted to process the submitted data. 
15 According to another aspect of the present invention, a computerized 

database for a system for managing the delivery of products is provided that 
includes an intermediate database including interim stored data and submitted 
data, and a submitted database including the submitted data. 

According to another aspect of the present invention, a system for 
20 managing the delivery of products is provided that includes means for 

permitting one or more thin clients to enter data related to the delivery of the 
products, means for storing interim saved data and submitted data, means for 
storing submitted data, and means for processing the submitted data. 

Brief Description of the Drawings 
25 FIG. 1 is a schematic illustration of a commercial transaction. 

FIG. 2 is a schematic illustration of an embodiment of a computer 
implemented system for managing the scheduling and delivery of products. 

FIG. 3 is a schematic illustration of a preferred embodiment for 
processing screen entry data, interim saved data, and submitted data in the 
30 system of FIG. 2. 
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FIG. 4 is a flow chart illustration of a preferred embodiment for 
processing screen entry data, interim saved data, and submitted data in the 
system of FIG. 2. 

FIG. 5 is a flow chart illustration of a preferred embodiment of a process 
5 for managing the scheduling and delivery of products using the system of FIG. 
2. 

FIG. 5a is an illustration of an embodiment of a screen display for the 
main menu of the process of FIG. 5. 

FIG. 6a is a flow chart illustration of a portion of an embodiment of the 
10 login process of the process of FIG. 5. 

FIG. 6b is a flow chart illustration of another portion of the embodiment 
of the login process of the process of FIG. 5. 

FIG. 6c is an illustration of an embodiment of a screen display for the 
login process of FIGS. 6a and 6b. 
15 FIG. 7a is flow chart illustration of an embodiment of a maintaining 

nominations process for the process of FIG. 5. 

FIG. 7b is an illustration of an embodiment of a screen display for the 
maintaining nominations process of FIG. 7a. 

FIG. 7c is an illustration of an embodiment of a screen display for the 
20 cycle selection process of the maintaining nominations process of FIG. 7a. 

FIG. 8a is flow chart illustration of an embodiment of a reviewing 
nominations process for the process of FIG. 5. 

FIG. 8b is an illustration of an embodiment of a screen display for the 
reviewing nominations process of FIG. 8a. 
25 FIG. 9a is flow chart illustration of an embodiment of a viewing 

nomination status process for the process of FIG. 5. 

FIG. 9b is an illustration of an embodiment of a screen display for the 
viewing nomination status process of FIG. 9a. 

FIG. 10a is flow chart illustration of an embodiment of a viewing 
30 nomination activity process for the process of FIG. 5. 
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FIG. 10b is an illustration of an embodiment of a screen display for the 
viewing nomination activity process of FIG. 10a. 

FIG. 11a is flow chart illustration of a portion of an embodiment of a 
maintaining confirmations process for the process of FIG. 5. 
5 FIG. lib is flow chart illustration of another portion of the embodiment 

of the maintaining confirmations process for the process of FIG. 5. 

FIG. 11c is an illustration of an embodiment of a screen display for the 
maintaining confirmations process of FIGS. 11a and lib. 

FIG. 12a is flow chart illustration of an embodiment of a viewing 
10 confirmation status process for the process of FIG. 5. 

FIG. 12b is an illustration of an embodiment of a screen display for the 
viewing confirmation status process of FIG. 12a. 

FIG. 13a is flow chart illustration of an embodiment of a maintaining 
predetermined allocations process for the process of FIG. 5. 
15 FIG. 13b is an illustration of an embodiment of a screen display for the 

maintaining predetermined allocations process of FIG. 13a. 

FIG. 14a is flow chart illustration of an embodiment of a viewing 
predetermined allocation status process for the process of FIG. 5. 

FIG. 14b is an illustration of an embodiment of a screen display for the 
20 viewing predetermined allocation status process of FIG. 14a. 

FIG. 15 is an illustration of an embodiment of a screen display for the 
reports options for the process of FIG. 5. 

FIG. 15a is flow chart illustration of an embodiment of a viewing 
customer reports process for the process of FIG. 5. 
25 FIG. 15b is an illustration of an embodiment of a screen display for the 

viewing customer reports process of FIG. 15a. 

FIG. 16a is flow chart illustration of an embodiment of a viewing partner 
reports process for the process of FIG. 5. 

FIG. 16b is an illustration of an embodiment of a screen display for the 
30 viewing partner reports process of FIG. 16a. 
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FIG. 17a is flow chart illustration of an embodiment of a viewing 
contract reports process for the process of FIG. 5. 

PIG. 17b is an illustration of an embodiment of a screen display for the 
viewing contract reports process of FIG. 17a. 
5 FIG. 18a is a flow chart illustration of an embodiment of a maintaining 

capacity release offers, bids & awards process for the process of FIG. 5. 

FIG. 18b is an illustration of an embodiment of a screen display for the 
maintaining capacity release offers, bids & awards process of FIG. 18a. 

FIG. 19a is a flow chart illustration of a portion of an embodiment of a 
10 viewing and entering system wide notices process for the process of FIG. 5. 

FIG. 19b is a flow chart illustration of another portion of the 
embodiment of the viewing and entering system wide notices process of FIG. 
19a. 

FIG. 19c is a flow chart illustration of another portion of the embodiment 
15 of the viewing and entering system wide notices process of FIG. 19a. 

FIG. 19d is an illustration of an embodiment of a screen display for the 
maintaining capacity release offers, bids & awards process of FIGS. 19a, 19b 
and 19c. 

FIG. 19e is an illustration of an embodiment of a screen display for the 
20 system wide notice detail option of the maintaining capacity release offers, bids 
& awards process of FIGS. 19a, 19b and 19c. 

FIG. 20a is flow chart illustration of an embodiment of a viewing 
operationally available and unsubscribed capacity (OAUC) reports process for 
the process of FIG. 5. 
25 FIG. 20b is an illustration of an embodiment of a screen display for the 

OAUC reports process of FIG. 20a. 

FIG. 21a is a flow chart illustration of the administration options process 
of the process of FIG. 5. 

FIG. 21b is an illustration of an embodiment of a screen display of the 
30 main menu for the administration options process of FIG. 21a. 
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FIG. 22a is flow chart illustration of an embodiment of the user manager 
of the process of FIG. 21a. 

FIG. 22b is an illustration of an embodiment of a screen display of the 
user manager for the administration options process of FIG. 21a. 
5 FIG. 22c is an illustration of an embodiment of another screen display of 

the user manager for the administration options process of FIG. 21a. 

FIG. 23a is flow chart illustration of an embodiment of the group 
manager of the process of FIG. 21a. 

FIG. 23b is an illustration of an embodiment of a screen display of the 
10 group manager for the administration options process of FIG. 21a. 

FIG. 23c is an illustration of an embodiment of another screen display of 
the group manager for the administration options process of FIG. 21a. 

FIG. 24a is flow chart illustration of an embodiment of the menu 
manager of the process of FIG. 21a. 
15 FIG. 24b is an illustration of an embodiment of a screen display of the 

menu manager for the administration options process of FIG. 21a. 

FIG. 24c is an illustration of an embodiment of another screen display of 
the menu manager for the administration options process of FIG. 21a. 

FIG. 24d is an illustration of an embodiment of another screen display of 
20 the menu manager for the administration options process of FIG. 2 la. 

FIG. 24e is an illustration of an embodiment of another screen display of 
the menu manager for the administration options process of FIG. 21a. 

FIG. 25a is flow chart illustration of an embodiment of the application 
settings option of the process of FIG. 21a. 
25 FIG. 25b is an illustration of an embodiment of a screen display of the 

application settings for the administration options process of FIG. 21a. 

FIG. 26a is flow chart illustration of an embodiment of the database 
verification of the process of FIG. 21a. 

FIG. 26b is an illustration of an embodiment of a screen display of the 
30 database verification for the administration options process of FIG. 21a. 
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FIG. 27a is an illustration of an embodiment of a screen display of the 
server information for the administration options process of FIG. 21a. 

FIG. 28a is an illustration of an embodiment of a screen display of the 
main menu for the online help for the administration options process of FIG. 
5 21a. 

Detailed Description of the Illustrative Embodiments 

As illustrated in FIG. 1, in a commercial transaction 100, a user 105 
contracts to deliver a product 110 to a recipient 115 using a delivery resource 
provider 120. The product 110 may include, for example, oil, gas, electrical 

10 energy, telecommunication signals, durable goods, perishable goods, or other 
products. The delivery resource provider 120 may include, for example, a 
pipeline, a trucking line, an ocean cargo line, a railway cargo line, or other 
delivery system. In a preferred embodiment, the commercial transaction 100 is 
at least partially implemented using one or more of the following products: 

15 Altrade™, Altra™ Power, Altra™ Gas, Altra™ Pipeline, Altra™ Risk and Altra™ 
Exchange, all available from Altra Energy Technologies in Houston, Texas. 

In a preferred embodiment, in order to effectuate the delivery of the 
product 110, the user 105 further contracts with the delivery source provider 
120 to define the details of the delivery of the product 110 to the recipient 115, 

20 which may include, for example: (1) the delivery route, (2) the amount of 

product delivered, (3) the upstream sources of the product, (4) the downstream 
destinations of the product, (5) when the product will be delivered, (6) the 
allocation of the delivered product. As will be recognized by persons having 
ordinary skill in the art, having benefit of the present disclosure, the term 

25 upstream sources generally refers to sources of the product that are upstream 
relative to the delivery source provider 120. As will be recognized by persons 
having ordinary skill in the art, having benefit of the present disclosure, the 
term downstream destinations generally refers to destinations of the product 
that are downstream relative to the delivery source provider 120. As will be 

30 recognized by persons having ordinary skill in the art, having benefit of the 
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present disclosure, the term allocation generally refers to amount of delivered 
product allocated to corresponding recipient destinations. 

The present system preferably permits the user 105 and the delivery 
source provider 120 to define the contractual relationship regarding the 
5 shipment and delivery of the product 1 10 by providing an interactive system for 
managing the scheduling and delivery of the product 110 that permits the user 
105 and delivery source provider 120 to enter, view, and maintain nominations, 
predetermined allocations, and confirmations. As will be recognized by persons 
having ordinary skill in the art, having the benefit of the present disclosure, the 

10 term nomination generally refers to the process of proposing the details of the 
shipment and delivery of the product 110. As will be recognized by persons 
having ordinary skill in the art, having the benefit of the present disclosure, the 
term predetermined allocations generally refers to the process of defining the 
allocation of the delivered product among one or more recipients of the product. 

15 As will be recognized by persons having ordinary skill in the art, having the 
benefit of the present disclosure, the term confirmation generally refers to the 
process of approving and/or modifying a proposed confirmation or allocation. 

In a preferred embodiment, the present system for managing the 
scheduling and delivery of products is implemented as a Web based browser 

20 that allows users of the system to enter, view, and maintain nominations, 
predetermined allocations, and confirmations via the Internet. 

In a particularly preferred embodiment, the present system for managing 
the scheduling and delivery of products is implemented using the AltraWeb™ 
Version 3.0 Web-based browser product available from Altra Energy 

25 Technologies in Houston, Texas. In a preferred embodiment, the system for 
managing the scheduling and delivery of products permits delivery resource 
providers (e.g., pipelines, local distribution companies (LDCs), and gathering 
companies ) and delivery resource users (e.g., shippers, agents, operators and 
confirming parties) to enter, view and maintain nominations, predetermined 

30 allocations and confirmations via the Internet. 
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In a preferred embodiment, the present system for managing the 
scheduling and delivery of products is further implemented as an optional 
module of the Altra™ Pipeline product available from Altra Energy 
Technologies in Houston, Texas. 
5 In a preferred embodiment, the present system for managing the 

scheduling and delivery of products is further implemented in combination with 
the Altra™ Pipeline On-System Gas Control module and the Altra™ Pipeline 
GISB interface, both available from Altra Energy Technologies in Houston, 
Texas. As will be recognized by persons having ordinary skill in the art, having 

10 the benefit of the present disclosure, the term GISB refers to the Gas Industry 
Standards Board. As will be recognized by persons having ordinary skill in the 
art, having the benefit of the present disclosure, the term GISB interface refers 
to a file server and/or database management interface that complies with one or 
more GISB standards. 

15 In a preferred embodiment, the present system for managing the 

scheduling and delivery of products permits delivery service providers and users 
to increase their efficiency and streamline their nomination processes by 
off-loading the time-consuming task of entering and confirming nominations to 
shippers and operators and maintaining the predetermined allocations. 

20 In a preferred embodiment, the present system permits delivery service 

users (e.g., shippers, agents, and operators) and delivery service providers (e.g., 
pipelines, local distribution companies (LDCs), and gathering companies) to: (1) 
enter, view, edit and maintain nominations; (2) enter, view, edit and maintain 
confirmations; (3) enter, view, edit and maintain predetermined allocations; (4) 

25 generate customer, partner and contract reports; (5) enter, view, edit and 
maintain capacity release offers, bids & awards, including offers, system wide 
notices, and operationally available and unsubscribed capacity (OAUC); and (6) 
various administrative functions that permit a user to customize the operation 
of the system. 

30 In a preferred embodiment, the present system is implemented as a 

server based application that enables users of the system to access the system 



H-224706.1 



-10- 



CA 02328595 2000-12-18 

Docket No. 21702.52.05 

directly via the delivery service provider's website. Because the present system 
is server based there is no download required and the system uses the system 
user's Web browser. As a result, the service provider does not have to manage 
delivery of updates to end-users or worry about installation and compatibility 
5 issues. Furthermore, because the present system preferably uses the public 
Internet as the connection, users of the system can literally connect from 
anywhere - avoiding long distance charges that typically result from calling 
proprietary modem banks. 

In a preferred embodiment, the present system permits users to view 

10 administrative information. In a preferred embodiment, the present system 
permits users to view data about transportation contracts and access 
information about other companies who do business with the delivery service 
provider 120. In a preferred embodiment, the present system permits users to: 
(1) view custody transfer contracts (those contracts on which the user's 

15 company has nomination rights (as either shipper or agent) with the delivery 
service provider; (2) view business partner information (the user can view a list 
of companies (including phone numbers) that do business with the delivery 
service provider. In a preferred embodiment, the view partner information can 
be disabled by delivery service providers who do not wish to share or are not 

20 required to share this information among their users. In a preferred 

embodiment, this option can also be configured to list either all or only certain 
types of business partners (i.e., shippers or agents). 

In a preferred embodiment, the present system permits users of the 
system to manage nominations quickly and easily. In a preferred embodiment, 

25 the present system permits system users to enter, submit and edit nominations. 
In a preferred embodiment, the present system further supports the use of: (1) 
pathed; (2) pathed non-threaded; and (3) non-pathed nomination model types 
as defined by one or more GISB standards. In this manner, the present system 
permits system users to enter all of the information - from transportation paths 

30 to upstream sources and downstream destinations - that are typically needed to 
nominate the flow of gas on a transportation system. In a preferred 
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embodiment, nominations can also be amended to include: (1) additional paths 
as well as upstream and/or downstream; and (2) changes to an existing path. 

In a preferred embodiment, the present system permits users of the 
system to maintain nominations. In a preferred embodiment, the present 
5 system also allows system users to view and edit nominations that have already 
been accepted by the delivery service provider. In a preferred embodiment, 
system users can increase or decrease product volumes and/or edit ranks for a 
single day as well as a range of days. As will be recognized by persons having 
ordinary skill in the art, having benefit of the present disclosure, the term rank 

10 generally refers to an indication of the priority to be used in determining the 
order in which nominations are scheduled. Examples of rank include Rank = 1 
for the highest priority and Rank = 999 for the lowest priority. 

In a preferred embodiment, the present system permits system users to 
view confirmation responses. In a preferred embodiment, after a nomination is 

15 input to the system, the delivery service provider, or other authorized user, 
validates it. If there is any reason to reject the nomination for specific form or 
content reasons, a confirmation response itemizing problems with the 
nomination is generated. 

In a preferred embodiment, the present system permits system users to 

20 view nomination activity. In a preferred embodiment, the system permits 
system users to see the status of nominations for a particular meter and/or a 
contract for an entire month. As will be recognized by persons having ordinary 
skill in the art, having the benefit of the present disclosure, the term meter 
generally refers to a device for measuring the amount of product flow. In a 

25 preferred embodiment, the available information, which can be summarized by 
receipt/delivery meter category, includes: the amount nominated (submitted by 
the user, e.g., shipper or agent), the amount scheduled (any flow reductions 
caused by delivery service provider limitations/constraints), the amount 
confirmed (any flow reductions caused by limitations from the upstream or 

30 downstream confirming parties), the amount allocated (adjusted for actual 
measured flows) and monthly total volumes for the selected meter. 
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In a preferred embodiment, the present system permits system users to 
manage predetermined allocations. In a preferred embodiment, the system 
permits system users to enter, submit and edit predetermined allocations. By 
supporting all allocation tiers defined by the delivery service provider, the 
5 present system allows users (e.g., shippers and operators) to enter all of the 
information required to allocate the volumes to their respective parties. 

In a preferred embodiment, the present system permits system users to 
view confirmations of predetermined allocations. In a preferred embodiment, 
after a predetermined allocation is input into the system, the delivery service 
10 provider validates it. If there is any reason to reject the predetermined 
allocation, a quick response itemizing problems is generated. 

In a preferred embodiment, the present system permits system users to 
confirm product flows. In a preferred embodiment, the system permits system 
users to enter, edit, and submit confirmations of products flows at the 
15 confirmation levels defined by the service provider. In a preferred 

embodiment, the system permits confirming parties to confirm product flows, 
enter reduced volumes and provide reduction reason codes. 

In a preferred embodiment, the present system permits system users to 
view confirmations of confirmed gas flows. In a preferred embodiment, after a 
20 gas flow confirmation is input into the system, the delivery service provider 
validates it. If there is any reason to reject the gas flow confirmation, a quick 
response itemizing problems is generated. 

In a preferred embodiment, the present system permits system users to 
generate reports. In a preferred embodiment, the system permits system users 
25 to generate a contract report and/or a partner report. In a preferred 

embodiment, the system further permits system users to add new reports 
based on their specific requirements. 

Referring to FIG. 2, a preferred embodiment of a system 200 for 
managing the scheduling and delivery of products will now be described. The 
30 system 200 is preferably used to manage the scheduling and delivery of natural 
gas products. More generally, as will be recognized by persons of ordinary skill 
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in the art, having the benefit of the present disclosure, the system 200 may be 
utilized to manage the scheduling and delivery of any product. 

The system 200 preferably includes one or more thin clients 205, one or 
more hold/audit/edi clients 210, corresponding thin client firewalls 215, 
corresponding hold/audit/edi client firewalls 220, the Internet 225, a firewall 
230, a firewall 235, a web server 240, a site manager hold/audit/edi server 245, a 
hold/audit interface 250, a firewall 255, a hold/audit database server 260, a 
hold/audit database 265, a submitted database server 270, a submitted database 
275, and a hold/audit interface server 280. 

The thin clients 205 are preferably coupled to the web server 240 via the 
Internet 225. In a preferred embodiment, the thin clients 205 are coupled to 
the web server 240 via the Internet 225 using a conventional web browser such 
as, for example, Netscape™ or Microsoft Internet Explorer™. As will be 
recognized by persons having ordinary skill in the art, having the benefit of the 
present disclosure, the term thin client generally refers to a client in a 
client/server environment that performs very little data processing. In a 
preferred embodiment, the thin client 205 processes only keyboard input and 
screen output, and all application processing is done in the web server 240. In 
this manner, the thin client 205 does not need system software updates. The 
thin clients 205 may, for example, be delivery service users 105 and/or delivery 
service providers 120. 

In a preferred embodiment, the operating systems for the thin clients 205 
include Windows 95/98 with TCP/IP or a Microsoft NT Workstation 4.0. In a 
preferred embodiment, the configurations for the thin clients 205 include: (1) 
Microsoft Internet Explorer 4.72 (or greater); (2) Intel P166 MHZ Pentium 
CPU (or higher); (3) 32MB RAM for Windows 95-98, 64MB for NT Workstation 
4.0; (4) 15" SVGA Monitor; (5) 1MB of free hard drive space; and (6) 28.8 KB 
Modem or greater. 

The hold/audit/edi clients 210 are preferably coupled to the site manager 
hold/audit/edi server 245 via the Internet 225. The hold/audit/edi clients 210 
are preferably adapted to permit the recipient 115 to view transactions in the 
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system 200. As will be recognized by persons having ordinary skill in the art, 
having benefit of the present disclosure, the term EDI refers to electronic data 
interchange. In a preferred embodiment, the hold/audit/edi client 210 is 
adapted to permit the recipient 115 to view transactions in the system 200 
5 using an industry-standard electronic data interchange communication 

standard. In a preferred embodiment, the hold/audit/edi client 210 is adapted 
to permit the recipient 115 to view transactions in the system 200 using the X- 
12 industry-standard electronic data interchange communication standard. 
The thin client firewalls 215 are preferably coupled between the thin 

10 clients 205 and the Internet 225. As will be recognized by persons having 
ordinary skill in the art, the term firewall generally refers to a method for 
keeping a network secure. 

The hold/audit/edi client firewalls 220 are preferably coupled between the 
hold/audit/edi client 210 and the Internet 225. 

15 The Internet 225 is preferably coupled between the thin clients 205 and 

hold/audit/edi clients 210 and the web server 240 and the site manager 
hold/audit/edi server 245. More generally, the Internet 225 (or Web) may be 
replaced with, or supplemented by, one or more local-area-networks (LAN) 
and/or wide-area-networks (WAN). 

20 The firewall 230 is preferably coupled between the Internet 225 and the 

web server 240. 

The firewall 235 is preferably coupled between the Internet 225 and the 
site manager hold/audit/edi server 245. 

The web server 240 is preferably coupled to the thin clients 205 via the 

25 Internet 225, the hold/audit database server 260, and the submitted database 
server 270. The web server 240 is preferably adapted to service the thin clients 
205 using active server web pages. In this manner, the thin clients 205 
preferably process only keyboard input and screen output, and all application 
processing is done in the web server 240. The web server 240 is preferably 

30 adapted to interface with the hold/audit database 265 via the hold/audit 

database server 260 and the submitted database 275 via the submitted database 
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server 270. In a preferred embodiment, the web server 240 is adapted to 
interface with the hold/audit database 265 and the submitted database 275 
using the OLEDB (OLE DataBase) programming interface. As will be 
recognized by persons having ordinary skill in the art, OLEDB is a 
5 programming interface for data access available from Microsoft. 

In a preferred embodiment, the web server 240 includes hardware having 
dual Intel Pentium/DEC Alpha Processors 300+ MHZ, and software having 
Windows NT 4.0 with Service Pack #4, Microsoft IIS 4.0 Web Server (Option 
Pack #4), Seagate Crystal Reports 7.0 Professional, and RDMS Client (Oracle 

10 for Windows NT or SQL Server Client). 

The site manager hold/audit/edi server 245 is preferably coupled to the 
hold/audit/edi client 210 via the Internet 225, the hold/audit interface install 
250, and the hold/audit database server 260. The site manager 
hold/audit/edi/server 245 is preferably adapted to interface with the hold/audit 

15 database 265 via the hold/audit database server 260. The site manager 

hold/audit/edi/server 245 is preferably adapted to interface with the hold/audit 
database 265 using the ODBC (Open DataBase Connectivity) programming 
interface. As will be recognized by persons having ordinary skill in the art, 
ODBC refers to a conventional database programming interface available from 

20 Microsoft that provides a common language for Windows applications to 

access databases on a network. In a preferred embodiment, the site manager 
hold/audit/edi server 245 is adapted to permit the hold/audit/edi client 210 to 
view transactions in the system 200 using the X-12 industry-standard electronic 
data interchange communication standard. 

25 In a preferred embodiment, the hold/audit/edi server 245 includes 

hardware having dual Intel Pentium/DEC Alpha Processors 300+ MHZ, and 
software having Windows NT 4.0 with Service Pack #4, Microsoft IIS 4.0 Web 
Server (Option Pack #4), Seagate Crystal Reports 7.0 Professional, and RDMS 
Client (Oracle for Windows NT or SQL Server Client). 

30 The hold/audit interface 250 is preferably coupled to the site manager 

hold/audit/edi server 245, the hold/audit database server 260, the submitted 
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database server 270, and the hold/audit interface server 280. The hold/audit 
interface 250 is preferably adapted to interface with the hold/audit database 265 
via the hold/audit database server 260 and the submitted database 275 via the 
submitted database server 270. In a preferred embodiment, the hold/audit 
5 interface 250 is adapted to interface with the hold/audit database 265 and the 
submitted database 275 using the OLEDB (OLE DataBase) programming 
interface. As will be recognized by persons having ordinary skill in the art, 
OLEDB is a programming interface for data access available from Microsoft. In 
several alternative embodiments, the hold/audit interface install 250 and the 
10 hold/audit interface database server 280 are combined on either side of the 
firewall 255. 

The firewall 255 is preferably coupled between the web server 240, the 
site manager hold/audit/edi server 245, the hold/audit interface 250 and the 
hold/audit database server 260, the submitted database server 270, and the 
15 hold/audit interface database server 280. 

The hold/audit database server 260 is preferably coupled to the web 
server 240, the site manager hold/audit/edi server 245, the hold/audit interface 
250, the hold/audit database 265, and the hold/audit interface database server 
280, 

20 In a preferred embodiment, the hold/audit database server 260 includes: 

a Microsoft SQL Server 6.5 with Service Pack #5 on NT 4.0 Server with Service 
Pack #4, and/or an Oracle 7.3.4 Server on NT 4.0 Server with Service Pack #4 
or UNIX Server. 

The hold/audit database 265 is coupled to the hold/audit database server 
25 260. The hold/audit database 265 is preferably adapted to hold data files that 
include: (1) intermediate saved data and (2) submitted data. In a preferred 
embodiment, the hold/audit database 265 is provided in compliance with GISB 
standard 1.3. 

The submitted database server 270 is preferably coupled to the web 
30 server 240, the hold/audit interface 250, the submitted database 275, and the 
hold/audit interface database server 280. 
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In a preferred embodiment, the submitted database server 270 includes: 
a Microsoft SQL Server 6.5 with Service Pack #5 on NT 4.0 Server with Service 
Pack #4, and/or an Oracle 7.3.4 Server on NT 4.0 Server with Service Pack #4 
or UNIX Server. 

5 The submitted database 275 is coupled to the submitted database server 

270. The submitted database 275 is preferably adapted to hold data files that 
include: (1) intermediate saved data and (2) submitted data. In a preferred 
embodiment, the submitted database 275 is provided in compliance with GISB 
standard 1.3. 

10 The hold/audit interface database server 280 is coupled to the hold/audit 

interface 250, the hold/audit database server 260, and the submitted database 
server 270. The hold/audit interface database server 280 is preferably adapted 
to interface with the hold/audit database 265 via the hold/audit database server 
260 and the submitted database 275 via the submitted database server 270. In 

15 a preferred embodiment, the hold/audit interface database server 280 is adapted 
to interface with the hold/audit database 265 and the submitted database 275 
using the OLEDB (OLE DataBase) programming interface. As will be 
recognized by persons having ordinary skill in the art, OLEDB is a 
programming interface for data access available from Microsoft. 

20 In a preferred embodiment, the hold/audit interface database server 280 

includes: a Microsoft SQL Server 6.5 with Service Pack #5 on NT 4.0 Server 
with Service Pack #4, and/or an Oracle 7.3.4 Server on NT 4.0 Server with 
Service Pack #4 or UNIX Server. 

Referring to FIG. 3, in a preferred embodiment, during operation of the 

25 system 200, system data is classified as either: (1) screen entry data; (2) interim 
saved data; or (3) submitted data. Screen entry data includes data that exists 
within the thin client 205. Interim saved data 310 includes screen data that has 
been saved by the thin client 205, or automatically saved by the system 200, 
prior to actual submission for processing by the system 200. Submitted data 

30 315 includes date submitted by the thin client 205 for actual processing by the 
system 200. In a preferred embodiment, all interim saved data 310 is saved 
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within the hold/audit database 265. In a preferred embodiment, all submitted 
data is saved within both the hold/audit database 265 and the submitted 
database 275. In this manner, the hold/audit database 265 provides both: (1) a 
temporary hold file for interim saved data 310; and (2) an audit file for 
5 verification of transactions by thin clients 205 using the system 200. More 
generally, in several alternative embodiments, the system 200 includes an N- 
tiered database structure, where N is greater than or equal to 2. In this 
manner, the database is optimally distributed and maintained. 

Referring to FIG. 4, during operation of the system 200, the thin client 

10 205 preferably interacts with the system 200 using a process 400 for processing 
data that includes the steps of: entering, editing, and/or viewing screen data in 
step 405; selecting an interim save of the screen data in step 410; selecting to 
submit the screen data in step 415; saving the screen data to the hold/audit 
database in step 420; and saving the screen data to the hold/audit database and 

15 the submitted database in step 425. 

In a preferred embodiment, in step 405, the thin client 205 is permitted 
to enter, edit, and/or view data. In a preferred embodiment, in step 405, the 
thin client 405 may enter new data into one or more blank screen data entry 
locations and/or retrieve previously saved interim or submitted data for further 

20 editing. 

In a preferred embodiment, the thin client 205 may then elect to interim 
save the screen data in step 410 or to submit the screen data for processing by 
the system 200 in step 415. Alternatively, the system 200 may automatically 
save screen data as interim data on a predetermined basis. If the screen data is 

25 interim saved in step 410, then the system 420 saves the interim data in the 
hold/audit database 265. If the screen data is submitted in step 415, then the 
system saves the submitted data into both the hold/audit database 265 and the 
submitted database 275 in step 425. 

Referring to FIGS. 5 and 5a, in a preferred embodiment, during 

30 operation of the system 200, the system 200 implements a process 500 for 

managing the scheduling and delivery of natural gas products that includes the 
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steps of: logging into the system 200 in step 502; selecting nomination options 
in step 504; nurinfarining nominations in step 506; reviewing nominations in 
step 508; generating nomination status reports in step 510; viewing nomination 
activity in step 512; selecting confirmation options in step 514; maintaining 
5 confirmations in step 516; generating confirmation status reports in step 518; 
selecting predetermined allocation options in step 520; maintaining 
predetermined allocations in step 522; generating predetermined allocation 
status reports in step 524; selecting report options in step 526; generating 
customer reports in step 528; generating partner reports in step 530; generating 

10 contract reports in step 532; selecting capacity release options in step 534; 

viewing offers, bids or awards in step 536; view system wide notices in step 538; 
view operationally available and unsubscribed capacity in step 540; and select 
administration options in step 542. In several alternative embodiments, the 
process 500 is preferably adapted to manage the scheduling and delivery of 

15 other products, such as, for example, durable goods, perishable goods, and 
commodities. 

In a preferred embodiment, as illustrated in FIGS. 6a, 6b and 6c, in step 
502, the thin client 205 logs into the system 200 using a login process 502 that 
includes the steps of: accessing the system website in step 602; checking for a s 

20 user identification cookie in step 604; displaying a blank in the user 

identification field in step 606; entering the user identification in step 608; 
entering the user password in step 612; checking the entered user identification 
and password for validity in step 614; display error message in step 616; 
checking for a user defaults cookie in step 618; using the user defaults in step 

25 620; and continuing in step 622. As will be recognized by persons having 

ordinary skill in the art, having the benefit of the present disclosure, the term 
cookie refers to data that is created by a conventional Web server that is stored 
on a user's computer. 

In a preferred embodiment, in step 602, the thin client 205 accesses the 

30 system website. In a preferred embodiment, the system website is maintained 
and operated by the provider 110. 
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In a preferred embodiment, in step 604, the system 200 checks for a user 
cookie that includes the user identification for the thin client 205. 

In a preferred embodiment, if a user identification cookie is not found, 
then in step 606, the user identification field is blank. The thin client 205 then 
5 enters the user identification in step 608. 

In a preferred embodiment, is a user identification cookie is found, then 
in step 610, the user identification is entered into the user identification field. 

In a preferred embodiment, in step 612, the thin client 205 enters a 
password. 

10 In a preferred embodiment, in step 614, the user identification and user 

password are checked for validity. If the user identification and/or user 
password are invalid, then an error message is displayed on the thin client in 
step 616. 

In a preferred embodiment, in step 618, the system 200 checks for user 

15 default cookies. In a preferred embodiment, the user default cookies include 
default values for system variables such as, for example, the pipeline and/or the 
contract and/or the gas day. 

If user default cookie data is found then the found user default data is 
used by the system 200 in step 620. The system 200 then continues in step 622 

20 and prompts the thin client 205 to select one of the following: options for 
nominations in step 504; options for confirmations in step 514; options for 
predetermined allocations in step 520; options for reports in step 526; options 
for capacity release in step 534; and options for administration in step 542. 

In a preferred embodiment, in step 504, the thin client 205 selects from 

25 among the nomination options of: maintaining nominations in step 506; 

reviewing nominations in step 508; viewing the status of nominations in step 
510; and viewing nomination activity in step 512. The thin client 205, in step 
504, can further preferably switch to any one of the following: confirmation 
options in step 514; predetermined allocation options in step 520; report options 

30 in step 526; capacity release options in step 534; administration options in step 
542; and exiting the system 200. 
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In a preferred embodiment, as illustrated in FIGS. 7a and 7b, 
maintaining nominations in step 506 includes the steps of: begin maintaining 
nominations in step 705; entering nomination data in step 710; retrieving 
corresponding nomination data in step 715; optionally selecting interim saving 
5 of nomination data in step 720; interim saving nomination data in step 725; 
optionally selecting submitting nomination data in step 730; saving submitted 
nomination data in step 735; optionally continuing to maintain nominations in 
step 740; and returning to the nomination options step 504 in step 745. In a 
preferred embodiment, maintaining options in step 506 permits a thin client 
10 205 to enter new nominations and/or edit previously interim saved or submitted 
nominations. 

In a preferred embodiment, in step 710, the thin client 205 may add 
and/or edit nomination data that includes one or more of the following: the 
pipeline, the contract, the start date, the end date, the contract type, the service 
15 level, the model type, the nomination unit (Nom Unit), the balance table 
information, the path information, the receipt information, and the delivery 
information. 

In a preferred embodiment, the balance table information includes one or 
more of the following: the path, points, and difference (DIFF) for the receipt 
20 total (REC TOTAL), the fuel, and the delivery total (DEL TOTAL). 

In a preferred embodiment, the path information includes one or more of 
the following: the tracking number (TRACK NO), the transaction type (TRANS 
TYPE), the cycle number, the receipt meter (REC METER), the delivery meter 
(DEL METER), the package ID, the receipt rank, the receipt volume, the fuel 
25 percent, the delivery rank, and the delivery volume. 

In a preferred embodiment, the receipt information includes one or more 
of the following: the path total, the point total, the difference, the tracking 
number (TRACK NO), the transaction type (TRANS TYPE), the cycle number, 
the receipt meter (REC METER), the package ID, the upstream contract (UP 
30 CONTRACT), the upstream entity (UP ENTITY), the rank, and the volume. 
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In a preferred embodiment, the delivery information includes one or 
more of the following: the path total, the point total, the difference, the tracking 
number (TRACK NO), the transaction type (TRANS TYPE), the cycle number, 
the delivery meter (DEL METER), the package ID, the downstream contract 
5 (DOWN CONTRACT), the downstream entity (DOWN ENTITY), the rank, and 
the volume. 

In a preferred embodiment, the thin client 205 may further change 
and/or select the cycle. In a preferred embodiment, upon selecting the 
CHANGE CYCLE option, as illustrated in FIG. 7c, the thin client 205 may 
10 select from a plurality of cycles. In a preferred embodiment, a cycle grid display 
provides the thin client 205 with the following information for each cycle: (1) 
the cycle number; (2) the cycle name; (3) the cycle status; and (4) the cycle 
description. 

In a preferred embodiment, in step 715, one of more of the nomination 
15 data entries are automatically provided and displayed by the system 200 on the 
thin client 205 as a function of default values for the thin client 205, and/or any 
combination of the nomination data entries entered by the thin client 205. In 
this manner, the system 200 facilitates the entry and processing of the 
nomination data. In a preferred embodiment, the system 200 further displays a 
20 status message and information regarding selected cycle. 

In a preferred embodiment, in step 720, the thin client 205 can interim 
save the nomination data. In a preferred embodiment, the thin client 205 can 
elect to interim save the nomination data by selecting an interim save of the 
nomination data. Alternatively, the system 200 automatically interim saves the 
25 nomination data based upon a user defined default timing or other incremental 
value. 

If the thin client chooses to interim save the nomination data, then the 
nomination data is preferably saved in the hold/audit database 265 in step 725. 
In step 730, the thin client 205 may then preferably choose to submit the 
30 nomination data for processing by the system 200. Nomination data that is 
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submitted for processing by the system may then be modified, confirmed or 
rejected by a thin client 205. 

If the thin client 205 submits the nomination data for processing by the 
system 200, then the nomination data is preferably saved in the hold/audit 
5 database 265 and the submitted database 275 in step 735. 

In step 740, the thin client 205 preferably may choose to continue 
entering nomination data in step 710 or return 745 to the nomination options 
in step 504. 

As illustrated in FIGS. 8a and 8b, in a preferred embodiment, reviewing 
10 nominations in step 508 preferably includes the steps of: entering nomination 
filter data in step 805; retrieving corresponding nomination data in step 810; 
optionally continuing in step 815; and returning in step 820. 

In a preferred embodiment, in step 805, the thin client 205 enters one or 
more nomination filter data in order to select corresponding nomination data 
15 for display. In a preferred embodiment, the nomination filter data includes the 
pipeline, the contract, the start date, the receipt meter filter (REC METER), 
and/or the delivery meter filter (DEL METER). 

In a preferred embodiment, in step 810, the system 200 retrieves and 
displays the nomination data on the thin client 205 corresponding to the 
20 nomination filter data entered in step 805. In a preferred embodiment, the 
nomination data includes one or more of the following: the contract type; the 
service level; the model type; the nomination unit (Nom Unit); the balance 
table; the path information; the receipt information; the delivery information; 
and the nomination status calender. 

In a preferred embodiment, the balance table information includes: the 
PATH, POINTS, and DIFF for each of the receipt total (REC TOTAL); the fuel; 
and the delivery total (DEL TOTAL). 

In a preferred embodiment, the path information includes one or more of 
the following: the tracking number (TRACK NO), the transaction type (TRANS 
TYPE), the receipt meter (REC METER), the delivery meter (DEL METER), 
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the package ID, the receipt rank and volume; the fuel percent; and the delivery 
rank and volume. 

In a preferred embodiment, the receipt information includes one or more 
of the following: the path total; the point total; the difference; the tracking 
5 number (TRACK NO), the transaction type (TRANS TYPE), the receipt meter 
(REC METER), the package ID, the upstream contract (UP CONTRACT), the 
upstream entity (UP ENTITY), the rank, and the volume. 

In a preferred embodiment, the delivery information includes one or 
more of the following: the path total; the point total; the difference; the tracking 
10 number (TRACK NO), the transaction type (TRANS TYPE), the delivery meter 
(DEL METER), the package ID, the downstream contract (DOWN 
CONTRACT), the downstream entity (DOWN ENTITY), the rank, and the 
volume. 

In a preferred embodiment, the nomination status calender information 

15 includes receipt volume information and delivery volume information for the 
selected time period. In a preferred embodiment, the receipt volume 
information includes one or more of the following: the status; the rank; and the 
volume for each day within the selected time period; and the volume total for 
the selected time period. In a preferred embodiment, the delivery volume 

20 information includes one or more of the following: the status; the rank; and the 
volume for each day within the selected time period; and the volume total for 
the selected time period. 

In a preferred embodiment, the thin client 205 may then choose to 
continue entering nomination filter information in step 815. If the thin client 

25 205 chooses to discontinue entering nomination filter data, then the system 200 
returns in step 820 to the nomination options in step 504. 

In a preferred embodiment, as illustrated in FIGS. 9a and 9b, viewing 
the status of nominations in step 510 includes the steps of: entering nomination 
filter data in step 905; retrieving corresponding nomination status information 

30 in step 910; optionally continuing in step 915; and returning in step 920. 
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In a preferred embodiment, in step 905, the thin client 205 enters one or 
more nomination filter data in order to select corresponding nomination data 
for display. In a preferred embodiment, the nomination filter data includes the 
pipeline, the contract, and/or the nomination submission date. 

In a preferred embodiment, in step 910, the system 200 retrieves and 
displays the nomination status information on the thin client 205 
corresponding to the nomination filter data entered in step 905. In a preferred 
embodiment, the nomination status information includes the nomination status 
and/or the validation messages. 

In a preferred embodiment, the nomination status information includes 
one or more of the following: the contract; the batch number; the time 
submitted; the time processed; and the status. 

In a preferred embodiment, the validation messages includes one or more 
of the following: the nomination tracking number (NOM TRACKING 
NUMBER); the validation code; and the validation message. 

In a preferred embodiment, the thin client 205 may then choose to 
continue entering nomination filter information in step 915. If the thin client 
205 chooses to discontinue entering nomination filter data, then the system 200 
returns in step 920 to the nomination options in step 504. 

In a preferred embodiment, as illustrated in FIGS. 10a and 10b, viewing 
nomination activity in step 512 includes the steps of: entering nomination filter 
data in step 1005; retrieving corresponding nomination activity information in 
step 1010; optionally continuing in step 1015; and returning in step 1020. 

In a preferred embodiment, in step 1005, the thin client 205 enters one 
or more nomination filter data in order to select corresponding nomination data 
for display on the thin client 205. In a preferred embodiment, the nomination 
filter data includes the pipeline, the contract, the meter, the gas day, and the 
point of view. In a preferred embodiment, the point of view may include the 
receipt point of view or the delivery point of view. In a preferred embodiment, 
the thin client 205 then presses the ACTIVITY button to retrieve the 
corresponding nomination activity information. 
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In a preferred embodiment, in step 1010, the system 200 retrieves and 
displays the nomination activity information on the thin client 205 
corresponding to the nomination filter data entered in step 1005. In a preferred 
embodiment, the nomination activity information includes one or more of the 
following: the gas day (DAY); the amount nominated (NOMINATED); the 
amount scheduled (SCHEDULED); the amount confirmed (CONFIRMED); the 
maximum available capacity (BEST AVAILABLE); and totals for each category. 

In a preferred embodiment, the thin client 205 may then choose to 
continue entering nomination filter information in step 1015. If the thin client 
205 chooses to discontinue entering nomination filter data, then the system 200 
returns in step 1020 to the nomination options in step 504. 

In a preferred embodiment, in step 514, the thin client 205 selects from 
among the confirmation options of: maintaining confirmations in step 516; and 
viewing the status of confirmations in step 518. The thin client 205 preferably 
may also switch to any one of the following: nomination options in step 504; 
predetermined allocation options in step 520; report options in step 526; 
capacity release options in step 534; administration options in step 542; and 
exiting the system 200. 

As illustrated in FIGS. 11a, lib and 11c, in a preferred embodiment, 
maintaining confirmations 516 includes the steps of: entering confirmation 
filter data in step 1110; retrieving corresponding data in step 1115; optionally 
confirming the retrieved corresponding data in step 1120; entering 
confirmation information for the retrieved corresponding data in step 1125; 
optionally selecting interim saving of the confirmation data in step 1130; 
interim saving the confirmation data in step 1135; optionally selecting 
submitting the confirmation data in step 1140; saving the submitted 
confirmation data in step 1145; optionally continuing to maintain 
confirmations in step 1150; and returning to the confirmation options step 514 
in step 1155. In a preferred embodiment, maintaining confirmations in step 
516 permits a thin client 205 to enter new confirmations and/or edit previously 
interim saved or submitted confirmations. 
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In a preferred embodiment, in step 1110, the thin client 205 enters 
confirmation filter information includes one or more of the following: the 
pipeline, the start date, and/or the end date. In several alternative 
embodiments, the confirmation filter data further includes one or more of the 
5 following: the contract, the contract type, the service level, the model type, the 
nomination unit, the balance table information, the path information, the 
receipt information, and the delivery information. 

In a preferred embodiment, the thin client 205 may further change 
and/or select the cycle as described above with reference to FIG. 7c. 

10 In a preferred embodiment, in step 1115, data corresponding to the 

confirmation filter data is retrieved and displayed by the system 200 on the thin 
client 205. In several alternative embodiments, the retrieved data corresponds 
to submitted nominations, submitted predetermined allocations, submitted 
confirmations, submitted capacity release offers, submitted capacity release 

15 bids, and/or submitted capacity release awards. In this manner, the thin client 
205 may respond to data submitted to the system 200 for processing. 

In a preferred embodiment, the retrieved data includes one or more of 
the following information: cycles information; meters information; and 
confirmation requests. 

20 In a preferred embodiment, the cycles information includes one or more 

of the following: the cycle number; the cycle name; the cycle status; and the 
cycle description. 

In a preferred embodiment, the meters information includes one or more 
of the following: operator confirmations indicator; operator confirmations for 

25 cycle indicator; cycle change indicator; CBE out of range indicator; the meter 
number (METER); the meter description; the direction of flow (DIR OF 
FLOW); the received volume (REC VOL); the delivered volume (DEL VOL); the 
total volume (TOTAL VOL); the CBE; the upper volume limit (HIGH LIMIT); 
and the lower volume limit (LOW LIMIT). 

30 In a preferred embodiment, the confirmation requests information 

includes one or more of the following: the DOF; the shipper, the contract; the 
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US/DS ENTITY; the US/DS; the package ID (PKG ID); the FLOWED; the 
PREV; the nominated volume (NOM VOL); the CUT TO; the CONF; the 
REAS; the cycle; the ASSIGN; and the SRC. 

In a preferred embodiment, the system 200 further displays one or more 
5 status messages corresponding to the confirmation filter data. Alternatively, 
the system 200 further displays system wide notices. 

In a preferred embodiment, in step 1120, the thin client 205 can elect to 
confirm the retrieved confirmation requests. 

If the thin client 205 elects to confirm the retrieved confirmation 
10 requests in step 1120, then the thin client 205 can then enter confirmation 
information for the retrieved confirmation requests in step 1125. In several 
alternative preferred embodiments, the thin client 205 can enter confirmation 
information for operator confirmations, or operator confirmations for cycle. In 
a preferred embodiment, the confirmation information can include one or more 
15 of the following: a validation of the retrieved confirmation requests; an approval 
of the retrieved confirmation requests; a disapproval of the retrieved 
confirmation requests; and/or feedback comments regarding the retrieved 
confirmation requests. 

In a preferred embodiment, in step 1130, the thin client 205 can interim 
20 save the confirmation data. In a preferred embodiment, the confirmation data 
includes the retrieved corresponding data and the confirmation information. In 
a preferred embodiment, the thin client 205 can elect to interim save the 
confirmation data by selecting an interim save of the confirmation data. 
Alternatively, the system 200 automatically interim saves the confirmation data 
25 based upon a user defined default timing or other incremental value. 

If the thin client chooses to interim save the confirmation data, then the 
confirmation data is preferably saved in the hold/audit database 265 in step 
1135. 

In step 1140, the thin client 205 may then preferably choose to submit 
30 the confirmation data for processing by the system 200. Confirmation data that 
is submitted for processing by the system may then be modified, confirmed, or 
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rejected by a thin client 205. In a preferred embodiment, the thin client 205 
may automatically confirm some or all of the outstanding confirmation requests 
by selecting Auto Confirm. 

If the thin client 205 submits the confirmation data for processing by the 
5 system 200, then the confirmation data is preferably saved in the hold/audit 
database 265 and the submitted database 275 in step 1145. 

In step 1150, the thin client 205 preferably may choose to continue 
entering confirmation filter data in step 1110 or return 1155 to the 
confirmation options in step 514. 

10 In a preferred embodiment, as illustrated in FIGS. 12a and 12b, viewing 

the status of confirmations in step 518 includes the steps of: entering 
confirmation status filter data in step 1205; retrieving the corresponding 
confirmation status information in step 1210; optionally continuing in step 
1215; and returning in step 1220. 

15 In a preferred embodiment, in step 1205, the thin client 205 enters one 

or more confirmation filter data in order to select corresponding confirmation 
data for display. In a preferred embodiment, the nomination filter data 
includes the pipeline, the confirmation submission date (SUBMIT DATE); and 
a status selection (STATUS). 

20 In a preferred embodiment, in step 1210, the system 200 retrieves and 

displays the confirmation status information on the thin client 205 
corresponding to the confirmation filter data entered in step 1205. In a 
preferred embodiment, the confirmation status information includes a status 
message; the quick responses; and the quick response batch # details. 

25 In a preferred embodiment, the status message corresponds to the 

confirmation filter information. Alternatively, the status message is a system 
wide notice. 

In a preferred embodiment, the quick response information includes one 
or more of the following: the batch number (BATCH #); the confirming 
30 requestor; the confirming party; the time submitted; and the status. 
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In a preferred embodiment, the quick response batch # details includes 
one or more of the following: the confirmation tracking number (TRACKING 
#); the validation code; the validation message; and the last update date for a 
selected quick response batch number. 
5 In a preferred embodiment, the thin client 205 may then choose to 

continue entering confirmation status filter information in step 1215. If the 
thin client 205 chooses to discontinue entering confirmation status filter data, 
then the system 200 returns in step 1220 to the confirmation options in step 
514. 

10 In a preferred embodiment, in step 520, the thin client 205 selects from 

among the predetermined allocation (PDA) options of: maintaining 
predetermined allocations in step 522; and viewing the status of predetermined 
allocations in step 524. The thin client 205 preferably may also switch to any 
one of the following: nomination options in step 504; confirmation options in 

15 step 514; report options in step 526; capacity release options in step 534; 
administration options in step 542; and exiting the system 200. 

As illustrated in FIGS. 13a and 13b, in a preferred embodiment, 
maintaining predetermined allocations (PDA) in step 522 includes: begin 
maintaining PDAs in step 1305; entering PDA data in step 1310; retrieving 

20 corresponding PDA data in step 1315; optionally selecting interim saving of 
PDA data in step 1320; interim saving PDA data in step 1325; optionally 
selecting submitting PDA data in step 1330; saving submitted PDA data in step 
1335; optionally continuing to maintain PDAs in step 1340; and returning to 
the PDA options step 520 in step 1345. In a preferred embodiment, 

25 maintaining PDAs in step 520 permits a thin client 205 to enter new PDAs 
and/or edit previously interim saved or submitted PDAs. 

In a preferred embodiment, in step 1310, the thin client 205 may add 
and/or edit PDA data that includes one or more of the following: the pipeline, 
the start date, the end date, the meter; the meter description; the direction of 

30 flow; the allocation tier selection; the delivery meter (DEL METER); the 

pipeline; the volume; the high/low rank filter selection; the DS (downstream) 
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entity; the volume; the method; the rank level; the limit value; and the high/low 
status. 

In a preferred embodiment, in step 1315, one of more of the PDA data 
entries are automatically provided and displayed by the system 200 on the thin 
5 client 205 as a function of default values for the thin client 205, and/or any 
combination of the PDA data entries entered by the thin client 205. In this 
manner, the system 200 facilitates the entry and processing of the PDA data. 

In a preferred embodiment, in step 1320, the thin client 205 can interim 
save the PDA data. In a preferred embodiment, the thin client 205 can elect to 
10 interim save the PDA data by selecting an interim save of the PDA data. 

Alternatively, the system 200 automatically interim saves the nomination data 
based upon a user defined default timing or other incremental value. 

If the thin client chooses to interim save the PDA data, then the PDA 
data is preferably saved in the hold/audit database 265 in step 1325. 
15 In step 1330, the thin client 205 may then preferably choose to submit 

the PDA data for processing by the system 200. PDA data that is submitted for 
processing by the system may then be modified, confirmed or rejected by a thin 
client 205. 

If the thin client 205 submits the PDA data for processing by the system 
20 200, then the PDA data is preferably saved in the hold/audit database 265 and 
the submitted database 275 in step 1335. 

In step 1340, the thin client 205 preferably may choose to continue 
entering/editing PDA data in step 1310 or return 1345 to the PDA options in 
step 520. 

25 In a preferred embodiment, as illustrated in FIGS. 14a and 14b, viewing 

the status of PDAs in step 524 includes the steps of: entering PDA filter data in 
step 1405; retrieving corresponding PDA status information in step 1410; 
optionally continuing in step 1415; and returning in step 1420. 

In a preferred embodiment, in step 1405, the thin client 205 enters one 

30 or more PDA filter data in order to select corresponding PDA status data for 
display. In a preferred embodiment, the PDA status filter data includes one or 
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more of the following: the pipeline, the PDA submission date (Submit Date), 
and the PDA status option (PDA Status). 

In a preferred embodiment, in step 1410, the system 200 retrieves and 
displays the PDA status information on the thin client 205 corresponding to the 
5 PDA status filter data entered in step 1405. In a preferred embodiment, the 
PDA status information includes the PDA status and/or the PDA validation 
messages. 

In a preferred embodiment, the PDA status information includes one or 
more of the following: the PDA number (NO.); the statement date; the time 
10 processed; and the status. 

In a preferred embodiment, the validation messages includes one or more 
of the following: the validation code; and the validation message. 

In a preferred embodiment, the thin client 205 may then choose to 
continue entering PDA status filter information in step 1415. If the thin client 
15 205 chooses to discontinue entering PDA status filter data, then the system 200 
returns in step 1420 to the PDA options in step 520. 

In a preferred embodiment, in step 526, the thin client 205 selects from 
among the report options of: customer reports in step 528; partner reports in 
step 530; and contract reports in step 532. The thin client 205 preferably may 
20 also switch to any one of the following: nomination options in step 504; 

confirmation options in step 514; predetermined allocation options in step 520; 
capacity release options in step 534; administration options in step 542; and 
exiting the system 200. In an exemplary embodiment, the screen display for 
step 526 is illustrated in FIG. 15. 
25 As illustrated in FIGS. 15a and 15b, in a preferred embodiment, the 

customer reports option 528 includes the steps of: entering customer report 
filter data in step 1505; retrieving corresponding customer report information 
in step 1510; optionally continuing in step 1515; and returning in step 1520. 
In a preferred embodiment, in step 1505, the thin client 205 enters one 
30 or more customer report filter data in order to select corresponding customer 
data for display. In a preferred embodiment, the customer report filter data 
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includes the company name, company code, customer number and/or the 
company telephone number. 

In a preferred embodiment, in step 1510, the system 200 retrieves and 
displays the customer information on the thin client 205 corresponding to the 
5 customer filter data entered in step 1505. In a preferred embodiment, the 
customer information includes the company name, company code, customer 
number and/or the company telephone number. 

In a preferred embodiment, the thin client 205 may then choose to 
continue entering customer filter information in step 1515. If the thin client 
10 205 chooses to discontinue entering customer filter data, then the system 200 
returns in step 1520 to the report options in step 526. 

As illustrated in FIGS. 16a and 16b, in a preferred embodiment, the 
partner reports option 530 includes the steps of: entering partner report filter 
data in step 1605; retrieving corresponding partner report information in step 
15 1610; optionally continuing in step 1615; and returning in step 1620. 

In a preferred embodiment, in step 1605, the thin client 205 enters one 
or more partner report filter data in order to select corresponding partner data 
for display. In a preferred embodiment, the partner report filter data includes 
the pipeline. 

20 In a preferred embodiment, in step 1610, the system 200 retrieves and 

displays the partner information on the thin client 205 corresponding to the 
partner filter data entered in step 1605. In a preferred embodiment, the 
partner information includes the company identification code (COMPANY ED), 
the company name, the Duns Number, the company phone, meter information 

25 and/or contract dates. 

In a preferred embodiment, the thin client 205 may then choose to 
continue entering partner filter information in step 1615. If the thin client 205 
chooses to discontinue entering partner filter data, then the system 200 returns 
in step 1620 to the report options in step 526. 

30 As illustrated in FIGS. 17a and 17b, in a preferred embodiment, the 

contracts reports option 532 includes the steps of: entering contract report 
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filter data in step 1705; retrieving corresponding contract report information in 
step 1710; optionally continuing in step 1715; and returning in step 1720. 

In a preferred embodiment, in step 1705, the thin client 205 enters one 
or more contract report filter data in order to select corresponding contract data 
5 for display. In a preferred embodiment, the contract report filter data includes 
the pipeline, and/or the date. 

In a preferred embodiment, in step 1710, the system 200 retrieves and 
displays the contract information on the thin client 205 corresponding to the 
contract filter data entered in step 1705. In a preferred embodiment, the 
10 contract information includes one or more of the following: the contracts 
available, the contract dates, and the points. 

In a preferred embodiment, the contracts available information includes 
one or more of the following: the contract number (CONTRACT); the shipper; 
the agent; the contract type; the service level; and the GISB model type. 
15 In a preferred embodiment, the contracts date information includes one 

or more of the following: the request date; the agreement date; the termination 
date; and the balance date. 

In a preferred embodiment, the points information includes one or more 
of the following: the receiving meter number (REC METER); the delivery meter 
20 number (DEL METER); the point of view; the rate unit; the priority; and the 
maximum quantity (MAX QUANTITY). 

In a preferred embodiment, the thin client 205 may then choose to 
continue entering contract filter information in step 1715. If the thin client 205 
chooses to discontinue entering contract filter data, then the system 200 
25 returns in step 1720 to the report options in step 526. 

In a preferred embodiment, in step 534, the thin client 205 selects from 
among the capacity release options of: offer, bids and awards in step 536; 
system wide notices in step 538; and operationally available and unsubscribed 
capacity (OAUC) in step 540. The thin client 205 preferably may also switch to 
30 any one of the following: nomination options in step 504; confirmation options 
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in step 514; predetermined allocation options in step 520; report options 526; 
administration options in step 542; and exiting the system 200. 

In a preferred embodiment, as illustrated in FIGS. 18a and 18b, 
maintaining capacity release offers, bid & awards in step 536 includes the steps 
5 of: begin maintaining capacity release offers, bids & awards in step 1805; 
entering capacity release offers, bids & awards data in step 1810; retrieving 
corresponding capacity release offers, bids & awards data in step 1815; 
optionally selecting interim saving of capacity release offers, bids & awards data 
in step 1820; interim saving capacity release offers, bids & awards data in step 

10 1825; optionally selecting submitting capacity release offers, bids & awards data 
in step 1830; saving submitted capacity release offers, bids & awards data in 
step 1835; optionally continuing to maintain capacity release offers, bids & 
awards in step 1840; and returning to the capacity release options step 534 in 
step 1845. In a preferred embodiment, maintaining capacity release offers, bids 

15 & awards in step 536 permits a thin client 205 to enter new capacity release 
offers, bids & awards and/or edit previously interim saved or submitted capacity 
release offers, bids & awards. 

In a preferred embodiment, in step 1810, the thin client 205 may enter 
and/or edit capacity release offers, bids & awards data that includes one or more 

20 of the following: the point of view (offers, bids or awards); the transportation 
service provider (Transportation Svc Provider); the capacity releasing company 
(Rel Company); the replacement/bidder company; the offer number (Offer No.), 
bid (Bid No.), or award number (Award No.); the offer, bid, or award recipient 
(To); the capacity release term start date (Rel Term Start Date); the capacity 

25 release term end date (Rel Term End Date); the bid period start date (Bid 
Period Start D/T); the bid period end date (Bid Period End D/T); the capacity 
release contract number (Rel K No.); the prearranged deal indicator 
(Prearranged Deal Ind); and the status. In a preferred embodiment, the thin 
client 205 may retrieve previously interim saved or submitted offers, bids and 

30 awards and/or create new offers, bids, and awards and/or submit offers, bids 
and awards. 
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In a preferred embodiment, in step 1815, one of more of the capacity 

release offers, bids & awards data entries are automatically provided and 

displayed by the system 200 on the thin client 205 as a function of default 

values for the thin client 205, and/or any combination of the capacity release 
5 offers, bids & awards data entries entered by the thin client 205. In this 

manner, the system 200 facilitates the entry and processing of the capacity 

release offers, bids & awards data. 

In a preferred embodiment, capacity release offers, bids & award 

information includes at least one or more of the following: the offer number 
10 (Offer No); the number of bids for the offer (No of Bids); the UPPD number; 

the capacity releasing company (Rel Company); the capacity releasing contract 

(Rel K No); the starting date for bids (Bid Period Start D/T); the ending date for 

bids (Bid Period End D/T); start date of the capacity release (Rel Term Start 

Date); the ending date of the capacity release (Rel Term End Date); and the 
15 status. 

In a preferred embodiment, in step 1820, the thin client 205 can interim 
save the capacity release offers, bids & awards data. In a preferred 
embodiment, the thin client 205 can elect to interim save the capacity release 

offers, bids & awards data by selecting an interim save of the capacity release *, f - ~* 

20 offers, bids & awards data. Alternatively, the system 200 automatically interim 

saves the capacity release, offers, bids & awards data based upon a user defined 

default timing or other incremental value. 

If the thin client chooses to interim save the capacity release offers, bids 

& awards data, then the capacity release offers, bids & awards data is preferably 
25 saved in the hold/audit database 265 in step 1825. 

In step 1830, the thin client 205 may then preferably choose to submit 

the capacity release offers, bids & awards data for processing by the system 200. 

Capacity release offers, bids & awards data that is submitted for processing by 

the system 200 preferably may then be modified, confirmed or rejected by a thin 
30 client 205. 
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If the thin client 205 submits the capacity release offers, bids & awards 
data for processing by the system 200, then the capacity release offers, bids & 
awards data is preferably saved in the hold/audit database 265 and the 
submitted database 275 in step 1835. 
5 In step 1840, the thin client 205 preferably may choose to continue 

entering capacity release offers, bids & awards data in step 1810 or return 1845 
to the capacity release options in step 534. 

As illustrated in FIGS. 19a, 19b, 19c and 19d, in a preferred embodiment, 
viewing and posting system wide notices in step 538 includes the steps of: 

10 optionally viewing system wide notices in step 1905; entering system wide 
notice filter information in step 1910; retrieving corresponding system wide 
notices in step 1915; optionally continuing to view system wide notices in step 
1920; optionally entering/editing system wide notices in step 1925; entering 
system wide notice data in step 1930; retrieving corresponding system wide 

15 notice data in step 1935; optionally interim saving system wide notice data in 
step 1940; interim saving system wide notice data in the hold/audit database 
265 in step 1945; optionally submitting the system wide notice data in step 
1950; saving the system wide notice data in step 1955; optionally continuing to 
enter/edit system wide notices in step 1960; optionally continuing to view and 

20 edit system wide notices in step 1965; and returning to the capacity release 
options in step 1970. In a preferred embodiment, viewing and posting system 
wide notices in step 538 permits the thin client 205 to view, enter, edit, interim 
save, and submit system wide notices. In a preferred embodiment, system wide 
notices can only be created/edited by the administrator of the system 200. 

25 In a preferred embodiment, in step 1905, the thin client 205 can elect to 

view system wide notices. 

In a preferred embodiment, in step 1910, the thin client 205 enters one 
or more system wide notice filter data in order to select corresponding system 
wide notices for display. In a preferred embodiment, the system wide notice 

30 filter data includes one or more of the following: the transportation service 

provider (transportation Svc Provider); the notice type; notice status; the range 
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of notice IDs; the critical notice code (Critical Notice); the notice effective date 
(Notice Eff Date); the notice end date; and the posting date. 

In a preferred embodiment, in step 1915, the system 200 retrieves and 
displays the corresponding system wide notices on the thin client 205 
5 corresponding to the system wide notice filter data entered in step 1910. In a 
preferred embodiment, the system wide notice information includes one or 
more of the following: the notice ID; the notice type; the critical notice indicator 
(Critical Notice Ind); the notice status; the notice effective date (notice EfTD/T); 
the notice end date; and the notice posting date. 
10 In a preferred embodiment, the thin client 205 may then choose to 

continue entering system wide notice filter information in step 1920. If the thin 
client 205 chooses to discontinue entering system wide notice filter data, then 
the thin client 205 may elect to optionally enter/edit system wide notices in step 
1925. 

15 In a preferred embodiment, in step 1930, the thin client 205 may enter 

and/or edit system wide notices include one or more of the following: the notice 
ID; the notice type; the critical notice indicator; the notice status, the notice 
effective data, the notice end date; and the notice posting date. In a preferred 
embodiment, the thin client 205 may retrieve previously interim saved or 

20 submitted system wide notices and/or create new system wide notices. 

In a preferred embodiment, in step 1935, one of more of the system wide 
notices are automatically provided and displayed by the system 200 on the thin 
client 205 as a function of default values for the thin client 205, and/or any 
combination of the system wide notice entries entered by the thin client 205. In 

25 this manner, the system 200 facilitates the entry and processing of the system 
wide notices. 

In a preferred embodiment, in step 1940, the thin client 205 can interim 
save the system wide notice data. Alternatively, the system 200 automatically 
interim saves the system wide notice data based upon a user defined default 
30 timing or other incremental value. 
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If the thin client 205 chooses to interim save the system wide notice data, 
then the system wide notice data is preferably saved in the hold/audit database 
265 in step 1945. 

In step 1950, the thin client 205 may then preferably choose to submit 
5 the system wide notice data for processing by the system 200. System wide 
notice data that is submitted for processing by the system 200 preferably may 
then be modified, confirmed or rejected by a thin client 205. 

If the thin client 205 submits the system wide notice data for processing 
by the system 200, then the system wide notice data is preferably saved in the 
10 hold/audit database 265 and the submitted database 275 in step 1955. 

In step 1960, the thin client 205 preferably may choose to continue 
entering system wide notices in step 1930. 

In step 1965, the thin client 205 preferably may choose to continue 
viewing and entering system wide notices or return in step 1970 to the capacity 
15 release options in step 534. 

As illustrated in FIG. 19e, in a preferred embodiment, the thin client 205 
can further view/enter detailed information for a system wide notice that 
includes one or more of the following: the transportation service provider 
(Transportation Svc Provider); the notice type; the critical notice indicator; the 
20 required response indicator (Required Response Ind); the notice ID; the prior 
notice ID; the notice status; the response date (Response D/T); the notice 
effective date (Notice Eff D/T); the notice end date (Notice End D/T); the 
posting date (Posting D/T); and the message. In a preferred embodiment, the 
thin client 205 may interim save or validate (submit) the system wide notice 
25 detailed information. 

In a preferred embodiment, as illustrated in FIGS. 20a and 20b, viewing 
the operationally available and unsubscribed capacity (OAUC) data in step 540 
includes the steps of: entering OAUC filter data in step 2005; retrieving 
corresponding OAUC information in step 2010; optionally continuing in step 
30 2015; and returning in step 2020. 
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In a preferred embodiment, in step 2005, the thin client 205 enters one 
or more OAUC report filter data in order to select corresponding OAUC data 
for display. In a preferred embodiment, the OAUC report filter data includes 
the transportation service provider (Transportation Svc Provider); the location 
5 (Loc); the available capacity effective date (Avail Cap Eff D/T); the available 
capacity end date (Avail Cap End D/T); the posting date (Posting D/T); and the 
capacity type (Cap Type). 

In a preferred embodiment, in step 2010, the system 200 retrieves and 
displays the OAUC information on the thin client 205 corresponding to the 
10 OAUC filter data entered in step 2005. In a preferred embodiment, the OAUC 
information includes one or more of the following: the OAUC path, and the 
OAUC details. 

In a preferred embodiment, the OAUC path information includes one or 
more of the following: the transportation service provider (Transportation Svc 
15 Provider); the location (Loc); and the location description (Loc Desc). 

In a preferred embodiment, the OAUC detailed information includes one 
or more of the following: the segment indicator (Segment Ind); the location 
capacity quantity (Loc Cap Qty); the quantity (Qty); the quantity available (Qty 

Avail); the IT indicator (IT Ind); the UOM; the available capacity effective date - **** 

20 (Avail Cap Eff); the available capacity end date (Avail Cap End); the posting 

date (Posting D/T); and notes. 

In a preferred embodiment, the thin client 205 may then choose to 

continue entering OAUC filter information in step 2015. If the thin client 205 

chooses to discontinue entering contract filter data, then the system 200 
25 returns in step 2020 to the capacity release options in step 534. 

As illustrated in FIGS. 21a and 21b, the administration options in step 

542 preferably include the steps of: select administration option in step 2105; 

user manager in step 2110; group manager in step 2115; menu manager in step 

2120; application settings in step 2125; database verification in step 2130; 
30 server information is step 2135; online help in step 2140; and exit 

administration in step 2145. In a preferred embodiment, the administration 
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options in step 542 preferably permit the thin client 205 and/or the 
administrator of the system 200 to customize the various user attributes of the 
system 200 and process 500. In a preferred embodiment, the administrator of 
the system 200 in the only user authorized to access the administration options 
5 in step 542. 

In a preferred embodiment, as illustrated in FIGS. 22a, 22b, and 22c, the 
user manager in step 2110 includes the steps of: selecting the user ID in step 
2205; optionally electing the assign, modify or remove user access in step 2210; 
assigning, modifying or removing user access in step 2215; optionally electing to 
10 continue in step 2220; and returning in step 2225. In a preferred embodiment, 
the user manager in step 2110 permits the thin client 205 and/or the 
administrator of the system 200 to assign, modify, and remove user access to 
the system 200. 

In a preferred embodiment, as illustrated in FIG. 22c, assigning, 

15 modifying or removing user access in step 2215 includes the ability to enter 
and/or edit user details that include one or more of the following: the user ID; 
the full name of the user; the telephone number of the user; the fax number of 
the user; the e-mail address of the user; the company that the user is associated 
with; the contact person at the company; the user group that the user is 

20 associated with; the expiration date of the user's access; the expiration date of 
the user's password; the date of the last login by the user; whether or not the 
user is active; notes regarding the user; the user's password; whether or not to 
change the user's password during the next user login; whether or not to lock 
the user's password; and whether or not the user is an internal user or an 

25 external user. 

In a preferred embodiment, as illustrated in FIGS. 23a, 23b, and 23c, the 
group manager in step 2115 includes the steps of: selecting the group ID in step 
2305; optionally electing the assign, modify or remove group access in step 
2310; assigning, modifying or removing group access in step 2315; optionally 

30 electing to continue in step 2320; and returning in step 2325. In a preferred 
embodiment, the group manager in step 2115 permits the thin client 205 and/or 
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the administrator of the system 200 to assign, modify, and remove group access 
to the system 200. 

In a preferred embodiment, as illustrated in FIG. 23b, the user groups 
include the administrator; operator; and shipper. 

In a preferred embodiment, as illustrated in FIG. 23c, in step 2315, the 
thin client 205 or administrator of the system 200 may enter and/or edit the 
following: the user group name; the description of the user group; whether or 
not the user group is active; and designate a contact person for the user group. 

In a preferred embodiment, as illustrated in FIGS. 24a, 24b, 24c, 24d, 
and 24e, the menu manager in step 2120 includes the steps of: optionally 
electing to add, edit, or remove menus or assign or remove menus for user 
groups in step 2405; optionally electing to add, edit, or remove menus in step 
2410; adding, editing or removing mentis in step 2415; optionally electing to 
continue in step 2420; optionally electing to assign or remove menus from user 
groups in step 2425; selecting a user group in step 2430; assigning or removing 
a menu from the selected user group in step 2435; optionally electing to 
continue in step 2440; and returning in step 2445. In a preferred embodiment, 
the menu manager in step 2120 permits the thin client 205 and/or the 
administrator of the system 200 to assign, modify, and remove menu items from 
the system 200. 

In a preferred embodiment, as illustrated in FIG. 24b, in step 2405, the 
thin client 205 may elect to add, edit or remove menus or assign or remove 
menus for user groups. 

In a preferred embodiment, as illustrated in FIG. 24c, in step 2415, the 
thin client 205 may add, edit or remove menu items by selecting one or more of 
the following for each menu item: adding a child; deleting; or moving the menu 
item. 

In a preferred embodiment, as illustrated in FIGS. 24d and 24e, in steps 
2430 and 2435, the thin client may assign or remove menu items for user 
groups including the administrator; the operator; or the shipper. In a preferred 
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embodiment, the thin client 205 may assign or remove menu items for user 
groups by granting or denying permission to use a selected menu item. 

In a preferred embodiment, as illustrated in FIGS. 25a and 25b, the 
application settings in step 2125 includes the steps of: selecting the system 
5 settings to view in step 2505; optionally electing to continue in step 2520; and 
returning in step 2525. In a preferred embodiment, the application settings in 
step 2125 permits the thin client 205 and/or the administrator of the system 200 
to view the application settings for the system 200. 

In a preferred embodiment, as illustrated in PIG. 25b, the viewable 
10 system settings include the standard user settings and the system settings. 

In a preferred embodiment, as illustrated in FIGS. 26a and 26b, the 
database verification in step 2130 includes the steps of: selecting a database 
and/or a database test in step 2605; optionally continuing in step 2620; and 
returning in step 2625. In a preferred embodiment, the database verification in 
15 step 2130 permits the thin client 205 and/or the administrator of the system 200 
to verify the current database tables and database settings for the system 200. 

In a preferred embodiment, as illustrated in FIG. 26b, in step 2605, the 
thin client 205 and/or the administrator of the system 200 can select one or 
more of the following conventional database tests: DUNS check, and PI data 
20 reference check. 

In a preferred embodiment, as illustrated in FIGS. 27a, the server 
information provided in step 2135 includes one or more of the following: the 
drive; the type of drive; the volume name; the file system; the path; the 
available space; the total space; the current directory; and the script timeout. 
25 In a preferred embodiment, the user manager in step 2110 permits the thin 
client 205 and/or the administrator of the system 200 to view basic server 
statistics for the system 200. 

In a preferred embodiment, as illustrated in FIGS. 28a, the online help in 
step 2140 provides online help for the system 200. In a preferred embodiment, 
30 the user manager in step 2110 permits the thin client 205 and/or the 
administrator of the system 200 to obtain online help for the system 200. 
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The following terms used within the present disclosure in describing the 
system 200 and the process 500 have the following general meanings: 

The term activity generally refers to transactions exchanged between 
users of the system 200. 
5 The term administrator generally refers to the administrator of the 

system 200. 

The term agent generally refers to a party authorized by the contracting 
party to transact business on behalf of the contracting party. 

The term allocation generally refers to the amount of delivered product 
10 allocated to corresponding recipient destinations. 

The term allocation tier generally refers to the layer in allocation process 
where multiple layers of trading partners are involved in the allocation. 
Examples of allocation tiers include producer, operator, and end user. In this 
manner, multiple sources of products, multiple deliverers of products, and 
15 multiple recipients of products may be provided. 

The term ASSIGN generally refers to the assignment of a resource or 
contractual right. 

The term available capacity effective date generally refers to the date 
upon which the posted available capacity becomes available. 
20 The term available capacity end date generally refers to the date upon 

which the posted available capacity ceases to be available. 

The term award generally refers to the contract resulting from the 
matching of an offer for capacity to one or more bids. 

The term award number generally refers to identification number 
25 assigned to the contract resulting from the matching of an offer for capacity to 
one or more bids. 

The term batch number generally refers to a unique identification 
number assigned by the system 200 to a group of data that is transmitted using 
the Internet 225 to a thin client 205. 
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The term best available generally refers to the optimal quantity of 
product that is used for allocation purposes. The quantity may come, for 
example, from actual, estimated, or other sources. 

The term bid generally refers to a transaction submitted by a bidder in 
5 reference to an offer of capacity whereby the bidder submits the terms of 
acceptance of the capacity. 

The term bid number generally refers to an identification number that is 
assigned to a bid. 

The term bid period start date generally refers to the first date on which 
10 interested parties may submit bids on a specific offer of capacity. 

The term bid period end date generally refers to the last date on which 
interested parties may submit bids on a specific offer of capacity. 

The term capacity release generally refers to the business practice 
whereby a capacity holder may offer their capacity for bidding by interested 
15 parties. The capacity may thereby be granted through an award of capacity to 
the winning bid. 

The term capacity release company generally refers to the entity 
releasing capacity in a specific offer. 

The term capacity release contract number generally refers to the 
20 contract number assigned to the capacity that is being offered by the capacity 
holder 

The term capacity release term start date generally refers to the first day 
on which the capacity being offered for release will be available for utilization 
by the acquiring party. 
25 The term capacity release term end date generally refers to the last day 

on which the capacity being offered for release will be available for utilization 
by the acquiring party. 

The term capacity segment indicator generally refers to an indicator that 
indicates that the capacity being offered is defined within a segment of a 
30 delivery resource (e.g. pipeline) by an indicator such as, for example, location. 
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The term capacity type generally refers to an indication of whether the 
capacity has primary rights, secondary firm rights, or interruptible rights. 
Examples of capacity types include primary to primary, primary to secondary, 
and secondary to secondary. 

The term CBE generally refers to confirmation by exception. 

The term change cycle generally refers to the process of moving from one 
nomination cycle to another nomination cycle. 

The term CONF generally refers to confirmation of the flow of a product, 
such as, for example, gas. 

The term confirmed generally refers to the flow of a product that has 
been confirmed by the party providing the delivery resource. 

The term confirmation generally refers to the process of approving 
and/or modifying a proposed confirmation or allocation. 

The term confirming party generally refers to the party conducting the 
confirmation process at a location. Examples of confirming parties include 
upstream operator and downstream operator. 

The term confirming requester generally refers to the party designated to 
initiate the confirmation process. Examples of confirming requesters include 
an operator, and a transportation service provider. 

The term contract generally refers to the agreement used to transact the 
delivery of products. 

The term contract agreement date generally refers to the date upon 
which the contract is in effect. 

The term contract dates generally refers to the group of dates designated 
in the contract that are used to identify the performance parameters of the 
contract. Examples of contract dates include: the request date, the agreement 
date, the termination date, and the balance date. 

The term contract request date generally refers to the date upon which a 
contracting party initiated the request to form a contract. 

The term contract termination date generally refers to the date that the 
contract ceases, or ceased to be, in effect. 
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The term contract type generally refers to the type of delivery contract. 
Examples of contract types include primary firm, interruptible, and secondary 
firm. 

The term critical notice generally refers to a notice issued by a user, 
5 delivery resource provider, or recipient that affects scheduling or adversely 
affects a scheduled product delivery flow. Examples of critical notices include a 
notice issued by a pipeline or operator that affects scheduling or adversely 
affects scheduled gas flow. 

The term customer generally refers to an entity having a contractual 
10 relationship with a delivery resource provider. 

The term CUT TO generally refers to a reduction in the quantity of 
delivered or scheduled product. 

The term cycle generally refers to the period in a day in which 
nominations, confirmations, and allocations are received from thin clients 205. 
15 Examples of cycle names include timely, evening, intradayl, and intraday 2. 
Examples of cycle descriptions include Timely: "Open for . 
Nominations/Confirmations," Evening: "Closed for Confirmations. 
Confirmations open on Cycle 1." 

The term cycle information generally identifies which cycle that a 
20 particular nomination or confirmation relates to. 

The term cycle name generally refers to the name given to a particular 
cycle. Examples of cycle names include timely, evening, intradayl, and 
intraday 2. Examples of cycle descriptions include Timely: "Open for 
Nominations/Confirmations," Evening: "Closed for Confirmations. 
25 Confirmations pen on Cycle 1." 

The term cycle status generally refers to the location in the cycle process 
for a particular cycle. Examples of cycle status include "Open for 
Nominations," "Open for Confirmations," and "Closed for Nominations." 
The term delivery generally refers to the exiting of a product from a 
30 transportation service provider system, or from the control of a contractual 
party on the transportation service provider system. 
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The term delivery meter generally refers to the location at which a 
product exits the transportation service provider system and/or leaves control of 
the delivery contract. Examples of delivery meters include 200D and 300D. 

The term delivery meter filter generally refers to the meter at which the 
5 product will be received by a recipient party from a transportation service 
provider. Examples of delivery meter filters include 200D and 300D. 

The term delivery point of view generally refers to the viewing 
perspective of a delivery location for a product. For example, the perspective 
may be on the upstream side (delivering side) of the delivery location or on the 
10 downstream side (receiving side) of the delivery location. 

The term delivery total generally refers to total quantity of product to be 
delivered to a particular delivery meter. 

The term delivery volume generally refers to the volume of product 
delivered to a delivery meter. 
15 The term difference generally refers to the quantity variance between 

two or more quantities. 

The term direction of flow generally refers to whether or not a particular 
location is delivering product from a delivery service resource to a recipient or 
transmitting product from a source into a delivery service resource. Examples 
20 of directions of flow include receipt and delivery. 

The term DOF (direction of flow) generally refers to the direction of flow 
of a product within a delivery resource provider. Examples of DOF include 
upstream and downstream. 

The term downstream generally refers to the disposition of a product 
25 after the product has been delivered from a delivery resource provider. 

The term downstream contract generally refers to the contract to which 
the product is transferred to. For example, when the product is delivered from 
the current delivery service provider to another delivery service provider 
system. 



H-224706.1 



-49- 



CA 02328595 2000-12-18 

Docket No. 21702.52.05 

The term downstream entity generally refers to the party holding title to 
the product once the product is delivered from the current delivery service 
provider to another delivery service provider system. 

The term DS Entity generally refers to the downstream entity. 
5 The term Dims Number generally refers to the unique identifier assigned 

to an entity by Dun & Bradstreet. 

The term end date generally refers to the last date of a date range. 

The term fuel generally refers to the quantity of product consumed or 
lost during the transportation of the product. Examples of fuel include the 
10 quantity of gas consumed or lost during the transportation of gas. 

The term fuel percent generally refers to the percentage of product lost 
or consumed during the transportation process. Examples of fuel percent 
include the percentage of gas consumed or lost during the transportation of gas. 

The term gas day generally refers to the 24 hour period that defines that 
15 art of a gas flow cycle and the end of a gas flow cycle. In the United States, the 
gas day is generally set at 9 a.m. central time to 9 a.m. central time. 

The term GISB (Gas Industry Standards Board) model type generally 
refers to the particular GISB structure used to submit a nomination for the 
transportation of gas. Examples of GISB model types include pathed, non- 
20 pathed, and pathed non-threaded. 

The term high limit generally refers to the maximum quantity that may 
be allocated to a single line item in an allocation. 

The term IT Ind generally refers to an indicator that designates whether 
or not interruptible gas is available at a location. More generally, IT Ind refers 
25 to products whose delivery may be interrupted. 

The term last update date generally refers to the latest date on which an 
update has or may occur. 

The term limit value generally refers to the quantity assigned to a high 
or low limit value in an allocation. 
30 The term location generally refers to a specific point, either physical or 

logical, in a delivery resource, where a product can be received into the delivery 
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resource, delivered to the delivery resource, transmitted from the delivery 
resource, or transferred among title holders to the product. Examples of 
locations include specific locations, either physical or logical, in a pipeline, 
where gas can be received into the pipeline, delivered to the pipeline, 
5 transmitted from the pipeline, or transferred among title holders to the gas. 

The term maintaining generally refers to entering, editing, interim 
saving and/or submitting system data. Examples of system data that are 
maintained include nominations, confirmations, predetermined allocations, 
capacity release offers, bids & awards, system wide notices, and operationally 
10 available and unsubscribed capacity. 

The term maximum quantity generally refers to maximum quantity that 
will be considered. 

The term meter generally refers to a device for measuring the amount of 
product flow. Examples of meters include gas flow meters. 
15 The term model type generally refers to the framework or data structure 

used to define the data being sent. Examples of model types include pathed, 
non-pathed, and pathed non-threaded. 

The term nomination generally refers to the process of proposing the 
terms and conditions for the shipment and delivery of a product. 
20 The term nomination tracking number generally refers to an 

identification number that is used to track the progress of a nomination within 
the system 200. 

The term nomination unit generally refers to the unit of measure in 
which the products included in a nomination are specified. Examples of 
25 nomination units include Dekatherms, Gigajoules, and Gigacalories. 

The term nominated generally refers to an item that has already been 
identified in a nomination. 

The term notice effective date generally refers to the date on which a 
posted notice becomes effective. 
30 The term notice end date generally refers to the date on which a posted 

notice ceases to be effective. 
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The term notice status generally refers to the current status of posted 
notice. Examples of notice status include posted, revised, and canceled. 

The term notice type generally refers to the classification of the notice. 
Examples of notice types include maintenance, curtailment, and operational 
flow order 

The term nomination volume generally refers to the quantity requested 
to be transported under a specific contract on a nomination line item. 

The term capacity release offer generally refers to a contract holder's 
posting of a portion of capacity that they wish to release. 

The term offer number generally refers to an identification number 
assigned to an offer. 

The term operator generally refers to the entity responsible for 
administration of a physical location within a transportation resource. 

The term operator confirmations generally refers to the process by which 
an operator exchanges information with interconnecting entities to verify the 
quantity of product that will flow during a specified period of time. 

The term operator confirmations for cycle generally refers to the 
confirmations corresponding to a specific daily cycle. 

The term operationally available and unsubscribed capacity (OAUC) 
generally refers to quantities of delivery capacity that are not being utilized. 
Examples of OAUC include posted quantities of volume flow at locations in a 
pipeline that are not being utilized in daily transportation (operationally 
available) or in firm contractual commitments (unsubscribed capacity). 

The term package ID generally refers to an identifier that a shipper of a 
product may assign to a nomination line item in order to differentiate that line 
item from other line items that would otherwise include the same components. 

The term partner generally refers to an entity with whom a party 
exchanges information or enters into contractual relationships. 

The term path generally refers to the route that a nominated quantity of 
product travels in a delivery resource. Examples of paths include the route that 
a nominated quantity of gas travels in a pipeline. 
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The term path total generally refers to the total quantity of product for a 
nominated path. Examples of paths include the total quantity of gas for a 
nominated path in a pipeline. 

The term pipeline generally refers to the entity that owns and/or 
5 operates a delivery resource. Examples of pipelines include the entity that owns 
and/or operates a section of physical section of a pipe used for the 
transportation of natural gas 

The term point total generally refers to the total amount of product 
delivered to or from a physical or logical location in a delivery resource. 
10 The term point of view generally refers to the viewing perspective when 

looking at data within the system 200. Examples of points of view include 
receipt, delivery, contract, location. 

The term posting date generally refers to the date on which an item or 
transaction is posted. 
15 The term prearranged deal indicator generally refers to a code 

designating an offer to release capacity having a pre-arranged bidder assigned 
to it at the time of posting. 

The term predetermined allocations generally refers to the process of 
defining the allocation of the delivered product among one or more recipients of 
20 the product. 

The term predetermined allocation option generally refers to a 
predefined allocation rule. 

The term preparer grid generally refers to a list of preparers, in grid 
format, from which one may choose a single preparer. 
25 The term preparer list generally refers to a list of preparers from which 

one may select a single preparer. 

The term PREV generally refers to previous. 

The term priority generally refers to the ranking assigned to a 
transaction. Examples of priority include 1, 2, 3 ... 
30 The term provider generally refers to a provider of a delivery resource. 
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The term quantity available generally refers to the quantity of product. 
Examples of quantity include a measure of natural gas identifying an amount 
available for utilization 

The term rank generally refers to an indication of priority. 
5 The term rank level generally refers to a numeric indication of rank. 

The term rate unit generally refers to the measuring unit basis for a particular 
rate. 

The term REAS (reason code) generally refers to the reason for a 
particular allocation adjustment. 
10 The term receipt generally refers to the entry of product into a delivery 

service provider system or into the control of the contractual party on a delivery 
service provider system. 

The term receipt meter generally refers to location where a product 
enters a delivery service provider system or into the control of the contractual 
15 party on the delivery service provider system. 

The term receipt meter filter generally refers to the listing of available 
receipt meters from which a thin client 205 may select. 

The term receipt point of view generally refers to the viewing perspective 
at a receipt location. The perspective may, for example, be on the upstream side 
20 (delivering side) of the receipt location or on the downstream side (receiving 
side) of the receipt location. 

The term receipt total generally refers to the total quantity of product 
received at a receipt meter. Examples of receipt totals include the total quantity 
of product received at a receipt meter. 

The term receipt volume generally refers to the quantity of product 
received at a receipt meter. 

The term recipient generally refers to the recipient of a delivered 
product. 

The term recipient grid generally refers to a grid of possible recipients 
from which one may select a single recipient. 
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The term replacement/bidder company generally refers to an entity that 
has placed a bid to become the entity that will use the capacity being released. 

The term segment indicator generally refers to an indicator that 
indicates that the capacity being offered is defined within a segment of a 
5 delivery resource or by some other indication (e.g. location). Examples of 
segment indicators include indications that capacity being offered is defined 
within a segment of a pipeline. 

The term scheduled generally refers to the stage within a cycle process 
where all product delivery has been nominated, confirmed, and the available 
10 delivery capacity has been allocated to the nomination transactions. 

The term service level generally refers to the type of service entered into 
in a contract. Examples of service levels include P2P and P2S. 

The term shipper generally refers to the entity transporting product 
under a contract. 

15 The term start date generally refers to the date of commencement. 

The term statement date generally refers to the date of generation of a 
report of information. 

The term submit generally refers to the submission of information by a 
thin client 205. 

20 The term submit date generally refers to the date on which a transaction 

was submitted by a thin client 205. 

The term start date generally refers to the date on which service begins. 

The term status generally refers to the status of a transaction. 

The term status message generally refers to a text message describing the 

25 status. 

The term system wide notice generally refers to a notice type that applies 
to the entire product delivery system, as opposed to notices that relate only to 
subsets of the product delivery system. 

The term system wide notice critical indicator generally refers to an 
30 indication of a system wide notice having a critical status that typically requires 
an immediate response. 
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The term system wide notice effective date generally refers to the date on 
which a system wide notice is placed into effect. 

The term system wide notice end date generally refers to the date on 
which a system wide notice ceases to be in effect. 

The term system wide notice posting date generally refers to the date on 
which a system wide notice is posted for viewing and/or made available for 
downloading. 

The term system wide notice ID generally refers to an identification of 
the system wide notice. 

The term system wide notice status generally refers to the status of a 
system wide notice. Examples of system wide notice status include active and 
withdrawn. 

The term system wide notice type generally refers to the type of system 
wide notice. Examples of system wide notice types include maintenance, 
curtailment, and press release. 

The term time processed generally refers to the time at which a 
transaction was processed. 

The term time submitted generally refers to the time at which a 
transaction was submitted. 

The term total volume generally refers to the total quantity of product 
for a particular location, contract, or entity. 

The term tracking number generally refers to an identification number 
assigned to a specific transaction for tracking purposes. 

The term transaction type generally refers to an indication of the type of 
business transaction. Examples of transaction types include current business, 
payback, and storage. 

The term transportation service provider generally refers to the entity 
responsible for operations and management of transactions on a physical 
pipeline. 

The term upstream generally refers to the disposition of a product prior 
to its entry into a delivery resource. 
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The term upstream contract generally refers to the contract that the 
product is transferred from and into a delivery resource. 

The term upstream entity generally refers to the party holding title to 
the product prior to the products entry into a delivery resource. 
5 The term UOM generally refers to unit of measure. 

The term UPPD generally refers to Upload to Pipeline of Prearranged 
Deals. The UPPD is preferably a unique identifier managed/assigned by the 
pipeline. 

The term US/DS generally refers to upstream/downstream. 
10 The term US/DS ENTITY generally refers to upstream/downstream 

entity. 

The term user generally refers to a user of a delivery resource. 

The term validation generally refers to the process of ensuring that the 
components of a transaction comply with the terms of the transaction. 
15 The term validation code generally refers to a code provided in response 

to the validation process that indicates a specific error or warning. Examples of 
validation codes include ENMQR100 and WNMQR300. 

The term validation message generally refers to a text explanation of the 
validation cone. Examples of validation messages include error, and receipt 
20 location not valid. 

The term view generally refers to the perspective from which data is 
displayed. 

The term volume generally refers to the numeric volume of product. 
Examples of volume include the numeric units of natural gas. 
25 In a preferred embodiment, the system 200 implemented using the 

process 500 is provided in compliance with the Gas Industry Standard Board 
(GISB) standards. 

In a preferred embodiment, the operation of the system 200 implemented 
using the process 500 is implemented using one or more of the software 
30 modules provided in the appendix to the present application and identified as: 
actjeftasp; actright.asp; actrightbotl .asp; addNPT.asp; addPath.asp; 
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addPNTU.asp; AEJTrigr.vbp; AET DA^bas; Allocation.cls; AUocationLevels.cls; 

AllocVolSel.bas; AsynchStartbas; awhelpdir.asp; aw2jreport.asp; 

aw2BL100.vbp; aw2BL200.vbp; aw2BL300.vbp; aw2BL400.vbp; aw2BL800.vbp; 

aw2BL900.vbp; awbuspro.asp; awCompanylnfoRpt.asp; awConfirmsStatus.asp; 
5 awconstraints.asp; awContractListRpt.asp; awContracts.asp; awintro.asp; 

awMaintainConfirmations.asp; awMaintainNoms.asp; awMaintainPDA.asp; 

awNomActivity.asp; awNomStatus.asp; awPartner.asp; awPDAStatus.asp; 

awReports.asp; awReviewNoms.asp; AWSystem.cls; awSystemBasics.asp; 

awtrademark.asp; balancetbl.asp; balancetbLinc; BalFuel.bas; balinfo.inc; 
10 BLNPT.vbp; BL_SchQt.vbp; blank.asp; bottomFrame.asp; BrowserError.asp; 

BuildCycleStatusGrid.asp; calcDelVol.asp; calcRecVol.asp; calendar.asp; 

CAllocation.cls; CAllocationDestProcess.cls; CAIlocationDetail.cls; 

CAllocationDetailList.cls; CAllocationGMSParmltem.cls; 

CAllocationGMSParmList.cls; CAllocationHeader.cls; 
15 CAllocationHeaderList.cls; CAllocationParameter.cls; CAQocationParmltem.cls; 

CAllocationParmList.cls; CAUocationQuantity.cls; CAllocationQuantityList.cls; 

CAUocationRulexls; CAllocationRules.cls; CAllocationSrcProcessxls; 

cancelPath.asp; CBreakUpRule.cls; CBreakUpRules.cls; CBuffer.cls; 

CCallBack.cls; CColWalker.cls; CC^nfirmationHeaderList.cls; 
20 CConfirmationLevel.cls; CConflrmationLevelRule.cls; CCk)nfirniationLevels.cls; 

CCoiifirmatioiiRequest.cls; CCk>iifirmationResponse.cls; 

CCk)nfirmReqDetail.cls; CConfinnReqDetailList.cls; CConfirmReqHeader.cls; 

CConfirmReqHeaderList.cls; CConfirmRequest.cls; 

CConfirmRespHeaderList.cls; CConfirmResponse.cls; 
25 CConflrmResponseQR.cls; CCk)nfirmRespQRHeaderList.cls; 

cConfRequestGridltem.cls; CContract.cls; CContractData.cls; 

CContractPoint.cls; CContractPoints.cls; CContractPointsData.cls; 

CContracts.cls; CCRQKDetaiLcls; CCRQRDetailListxls; CData.cls; 

CDataExchange.cls; CDataServices.cls; CDataSetltemxls; CDataSetIist.cls; 
30 CDatasetManager.cls; CEmpty.cls; CError.cls; CExistingNomServer.cls; 

cField.cls; cFields.cls; CFileItem.cls; CFiles.cls; cG811TSIN.cls; 
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cG811TSIN_Detail.cls; cG811TSIN_Details.cls; cG811TSIN_Header.cls; 

cG811TSIN_Headers.cls; cG811TSIN_Location.cls; cG81 lTSIN_Locations.cls; 

cG811TSIN_Package.cl8; cG865SQOP.cls; cG865SQOP_Detail.cls; 

cG865SQOP_Details.cls; cG865SQOP_Header.cls; cG865SQOP_Headers.cls; 
5 cG865SQOP_Package.cls; cG867MSIN.cls; cG867MSIN_Detail.cls; 

cG867MSIN_Details.cls; CGImpNomQR.cls; CGISBAllocation.cls; 

CGISBAUocationData.cls; CGISBAllocationDetail.cls; 

CGISBAllocationDetailList.cls; CGISBAllocationHeader.cls; 

CGISBAllo^tionHeaderlist.cls; CGISBCinfiraiReqDetaimst.cls; 
10 CGISBConfirmReqDetail.cls; CGISBConfirmReqDetailList.cls; 

CGISBConfirmReqHeader.cls; CGISBConfirmReqHeaderList.cls; 

CGISBConfirmRequest.cls; CGISBConfirmRespDetail.cls; 

CGISBConfirmRespDetailList.cls; CGISBConfirmRespHeader.cls; 

CGISBConfirmRespHeaderList.cIs; CGISBConfirmResponse.cls; 
15 CGISBConfirmResponseQR.cls; CGISBConfResponseQRxls; 

CGISBConfRespQRDetail.cls; CGISBConfRespQRDetailList.cls; 

CGISBConfRespQRHeader.cls; CGISBConfrespQRHeaderList.cls; 

CGISBDataset.cls; CGISBError.cls; CGISBErrors.cls; CGISBMeasurement.cls; 

CGISBMeasurementData.cls; CGISBNomination.cls; 
20 CGISBOpSchedQtyDetail.cls; CGISBOpSchedQtyDetaiLList.cls; 

CGISBOpSchedQtyHeader.clsjCGISBOpSchedQtyHeaderList.cls; 

CGISBOpSchedQuantity.cls; CGISBPDAxls; CGISBPDAData.cls; 

CGISBPDADetail.cls; CGISBPDADetailList.cls; CGISBPDAHeader.cls; 

CGISBPDAHeaderList.cls; CGISBPDAQR.cls; CGISBQuickResponse.cls; 
25 cGISBResponseDetail.cls; cGISBResponseHeader.cls; CGISBSchdQtyDetail.cls; 

CGISBSchdQtyDetailList.cls;CGISBSchdQtyHeader.cls; 

CGISBSchdQtyHeaderList.cls; CGISBSchdQtyQuantity.cls; 

CGISBSchdQtyQuantityList.cls; CGISBSchedQuantity.cls; cGISBSequence 

Number.cls; CGMSAllocation.cls; CGMSAllocationDataxls; 
30 CGMSAllocationDetaiLcls; CGMSAUocationDetailList.cls; 

CGMSAllocationHeader.cl8; CGMSAllocationHeaderList.cls; 
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cGMSCompanylnfo.cls; CGMSDataService.cls; CGMSDataset.cls; 

CGMSErrors.cls; CGMSMeasurement.cls; CGMSMeasurementDataxls; 

CGMSPDAxls; CGMSPDAData.cls; CGMSPDADetail.cls; 

CGMSPDADetaillist.cls; CGMSPDAHeader.cls; CGMSPDAHeaderlistcls; 
5 change Values.inc; checkDuplicatePath.asp; checkDuplicatePathU.asp; 

checkValidPath.asp; checkVolume.asp; clsTimer.cls; CMeasurement.cls; 

CMeasurementDestProcess.cls; CMeasurement Detail.cls; 

CMeasurementDetailList . els; CMeasurementGMSParmltem.cls; 

GMeasurementGMSParmList.cls; GMeasurementHeader.cls; 
10 CMeasurementHeaderList.cls; CMeasurementParameter.cls; 

CMeasurementSrcProcess.cls; CNCReqDetail.cls; CNCReqDetailList.cls; 

CNCReqHeader.cls; CNCRespDetail.cls; CNCRespDetailList.cls; 

CNCRespHeader.cls; CNomActivities.cls; CNomActivity.cls; 

CNomActivityData.cls; cNomActvy.cls; CNomDetail.cls; CNomDetailList.cls; 
15 CNomHeader.cls; CNomHeaderList.cls; CNomination.cls; CNomQRData.cls; 

CNomQRHeaderList.cls; CNomQuickResponse.cls; CNomQuickResponses.cls; 

cNomsActivity.cls; CNomStatusxls; CNomStatuses.cls; CNQRDetail.cls; 

CNQRDetailList.cls; CNQRHeder.cls; CollectionUtils.cls; colordefinition.asp; 

colordefinitionl.asp; colorRows.inc; ColTest.cls; columns.css; columnsPTH.css; 
20 Comlnfo.cls; Company.cls; Company_Info.rpt; Confirmations.asp; 

ConfirmationStatus.asp; Confirms.SWT; Confirms. vbg; Confirms. vbp; 

Confirms.vbw; ConfStatus.cls; contract.cls; Contract_List.rpt; contract02.asp; 

contract04.asp; contract06.asp; contractChange.asp; 

contractChangeRefresh.asp; convert.bas; cookieheaderl.asp; cookietest.asp; 
25 COpSchdDetail.cls; COpSchdQtydetail.cls; COpSchdQtyDetaillist.cls; 

COpSchdQtyHeader.cls; COpSchdQtyHeaderList.cls; COpSchedQuantity.cls; 

COpScheduleQty.cls; CParameterFactory.cls; CPartner.cls; CPartnerData.cls; 

CPartners.cls; CPDA.cls; CPDADetail.cls; CPDADetaillist.cls; 

CPDAGMSParntf tem.cls; CPDAGMSParmlist.cls; CPDAHeader.cls; 
30 CPDAHeaderListcls; CPDAParameter.cls; CPDAQRcls; CPDAQRDetailxls; 

CPDAQRDetailList.cls; CPDAQRHeader.cls; CPDAQRHeaderList.cls; 
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CPDASrcProcess.cls; CQuickResponse.cls; CreateNomFieldValidation.inc; 

cReductionReason.cls; cReductionReasonList.cls; CReportFiles.cls; 

CReportManager.cls; cRequestsList.cls; Criteria.asp; CRptDataService.cls; 

CRptGISBDataService.cls; CRptGMSDataService.cls; CRQRHeader.cls; 
5 CSchedQtyDetail.cls; CSchedQtyDetailList.cls; CSchedQtyHeader.cls; 

CSchedQuantity.cls; CSchedQuantityHeaderList.cls; CScheduleQty.cls; 

CString.vbp; CTitle.cls; CTitleList.cls; Cycles.asp; CycleStatusJavaScript.asp; 

Da_ado.vfop; DataServices.bas; DataSet.cls; DataSetNames.bas; DataXchg.vbp; 

dates.inc; DB_Login.£rm; DB_Login.frx; DB_Util.bas; dberror.asp; 
10 DBHelper.vbp; default.asp; Defaults.cls; delete.asp; deleteGISBNom.asp; 

delNPT.asp; DetailData.asp; DetailFrame.asp; Details.asp; disclaimer.asp; 

drawBalanceTable.asp; drawEmptyGridArea.asp; drawEntitySelect.asp; 

drawEntitySelectBox.asp; drawFilteredMeterList.asp; drawInputBlantasp; 

drawJSResizeFunction.asp; drawNomStatusArea.asp; drawNPTData.asp; 
15 drawNPTGridArea.asp; drawPNTCalendar.asp; drawPNTGridArea.asp; 

drawPNTPathData,asp; drawPNTUData.asp; drawSearchingDatabase.asp; 

drawStatusCalendarAreaNPT.asp; drawStatusCalendarAreaPNT.asp; 

drawTransTypeSelect.asp; drawTransTypeSelectBox.asp ; DS_G8 1 ITSIN.vb w; 

DSImpNomQR.vbp; DS ImpNomQR.vbw; Dummy.cls; Ed_SchQt.vbp; 
20 Edge_NPT.vbp; enumvar.bas; ErrorCodes.bas; Errorlnc.asp; errormessage.asp; 

filterRank.asp; fUterVolume.asp; finaltest.asp; footer.asp; formatValue.asp; 

frmTest.frm; fimTestfrx; ftie4style.css; ftiens4 js; Puel.cls; G811TSIN.bas; 

G811TSIN.vbp; G865SQOP.bas; G865SQOP.vbp; G867MSIN.bas; 

G867MSIN.vbp; G867MSIN_Package.cls; GBHelper.vbp; GBHelper.vbw; 
25 getCaption.asp; getclientsettings.asp; getContractInfo.asp; getContracts.asp; 

getCycleDropdown.asp; getCyclesList.asp; getCycleTable.asp; getDayList.asp; 

getDaysInMonth.asp; GetDT.bas; getFilteredMeterList.asp; 

getFirstOpenCycIe.asp; GetBISBRecipients.cls; GetLastDay.asp; 

getmeterDescription.asp; GetMeters.cls; getMonthLast.aspGetNoms.bas; 
30 getNomStatusCalDataNPT.asp; getNomStatusCalDataPNT.asp; 

getNPTData.asp; getPipelinelnfo.asp; getPipelines.asp; getPNTCycleData.asp; 
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getPNTData.asp; getPNTPointSum.asp; getPNTUCycleData.asp; 

getPNTUData.asp; GetPreparers.cls; GetRecipients.cls; 

GetStartAndEndDate.asp; GetTransType.cls; getYearListasp; 

GI_ImpNomQR.cls; GIJSchQt.vbp; GImpNomQR.bas; GISB.cls; 
5 GISB_NPT.vbp; GISBData.vbp; GISBData.vbw; gisbDefaults.bas; 

GISBModification.cIs; GISBObjects.vbp; GISBSeqN.vbw; GISBStat.vbg; 

GisbStat.vbp; GisbStat.vbw; GISBTransactProcessQueue.cls; GISBTrigger; 

GISBTrigger.cIs; GISBUtilities.cls; global.asa.build; GlobalModule.bas; 

Globals.bas; globalstyle.css; globalutils.asp; globalutils.inc; glossary.asp; 
10 GMS.cls; GMS_NPT.vbp; GMS_PNT.vbp; GMS_PTH.vbp; GMSBatchStuff.bas; 

GMSData.vbp; GMSData.vbw; gmsDUDepends.bas; gmsdllus.bas; 

GMSFuels.cls; GMSFuels.vbp; GMSObjects.vbp; grid_functions.asp; header.asp; 

Header xls; header .ess; HeaderData.asp; HeaderFrame.asp; HeaderFrame.asp; 

HeaderProcessing.inc; Headers.asp; helpcontent.asp; iAllocationltem.cls; 
15 iAllociationParmsxls; lApplicationDataset.cls; ICallBack.cls; iConfirmation.cls; 

IConiirmationLevelParm.cls; IConfirmationLevleProcess.cls; 

IConfirmationReqProcess.cls; IConfirmRequestParm.cls; 

IConfirmRespProcessxls; ICtonfirmRespQRProcess.cls; IContractParm.cls; 

IContractPoints.cls; IData.cls; IDataConnection.cls; IDataLoad.cls; 
20 IDataParameter.cls; IDataProcess.cls; EDataService.cls; IDataset.cls; 

IDestinationProcess.cls; iError.cls; IErrorMessage.cls; iEvent.cls; 

IGetDatasetBuffer.cls; IGISBDataLoadxls; IGISBDataService.cls; 

IGISBDataset.cls; iGISBDelete.cls; IGISBErrorMessage.cls; IGISBList.cIs; 

IGISBReference.cls; iGISBSave.cls; iGISBSubmit.cls; iGISBUpdate.cls; 
25 IGMSDataLoad.cls; IGMSDataService.cls; IGMSDataset.cls; iHeader.cls; 

ilnformation.cls; IList.cls; IListGISB.cls; imagedefinition.asp; iMeterltem.cls; 

iMeterParms.cIs; IMoveData.cls; IMoveDataParm.cls; 

ImpNomQRJ?acksage.cls; InfoCoLcls; InfoMan.vbp; InfoManager.cls; 

INomActivityParm.cls; iNominationData.cls; INominationProcess.cls; 
30 ENomQRParm.cIs; INomQRProcess.cls; INomStatusParm.cls; Interaction.cls; 

iteractiveRowDisplay.asp; Intraday.vbg; IntraDayNom.vbp; IntraDayNom.vbw; 
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iObjectlD.cls; IOpSchedQtyProcess.cls; IPartnerParm.cls; IPreparerltem.cls; 

iPreparerParms.cls; EProcessDataset.cls; iRecipientParms.cls; IReference.cls; 

IReportFactory.cls; ISchedQtyParm.cls; ISchedQtyProcess.cls; 

ISetDatesetBuffer.cls; isLeapYear.asp; iSQL.cls; IStr.cls; IUDT.cls; iValue.cls; 
5 IVarWlk.cls; jsActionKey.asp; jscookies.asp; jsFormatNumber.asp; 

jsrefreshNPTAdd.asp; jsrefreshPNTPathAdd.asp; jsrefreshPNTUAdd.asp; 

jsStatusMessages.asp; jsSubmitNom.asp; jsupdateNPTHeader.asp; 

localDefaults.bas; LogicalProcessOrders.asp; Login.cls; loginvalidation.asp; 

Main.bas; MainModule.bas; mainpage.asp; MainSub.bas; 
10 maint Jbottom_frame.asp; maint _gridl.asp; maint jjridl_hdr.asp; 

maint _grid2.asp; maint _grid2_hdr.asp; maint _grid3.asp; maint j*rid3_hdr.asp; 

maint_main.asp; maint_nom_drops.inc; maint_nom _grids.inc; 

MaintNPTdrops.inc; maint_NPT _grids.inc; maint_NPTl.asp; 

maint_NPTl_hdr.asp; maint_NPT2.asp; maint_NPT2_hdr.asp; 
15 maint_PTH.asp; maintPTHdrops.inc; maint PTH jjrids.inc; mainttop.asp; 

maintbal.asp; maintbal.inc; maintgrid.asp; maintnomOl.asp; maintnom02.asp; 

maintnommain.asp; Maintties.css; maintupdates.asp; menu.asp; Meter.cls; 

MeterListcls; Meters.asp; modJSchQtbas; mod200UDTs.bas; mod400.bas; 

modAW2_GMS.bas; modBLlOO.bas; modBL200.bas; modBL800,bas; 
20 modBL900.bas; modCString.bas; modDAex.bas; modDataBaseRoutine.bas; 

mo&DataBaseRoutines.bas; modEd_SchQt.bas; modEdgeNom.bas; 

modErrorCodes.bas; modPuel.bas; modGI_Noms.bas; modGIJSchQtbas; 

modGISB.bas; modGISBErrorCJodes.bas; modGMS_NPT.bas; 

modGMS_PNT.bas; modGMS_PTH.bas; modlmpQRbas; 
25 modMoveDataMgr.bas; modNomUDT.bas; modOnlyGisbUDT.bas; 

MouseEvents.asp; Move_SchQty.cls; MoveData.cls; MoveData.vbp; 

MoveMgr.vbp; Mover .vbg; Movergroup.vbg; MoverObjects.vbp; mRoutines.bas; 

msgbox.inc; mssccprj.scc; navbar.asp; newaltra3b.gif; newcolor.inc; 

nom_act_main.asp ; non_dropdowns.asp; nom_dropdowns2.inc; nom _grid.inc; 
30 nomjgridl.asp; nom __gridl_hdr.asp; nom_grid2.asp; nom jjrid2_hdr.asp; 

nomjgrid3.asp; nom _grid3_hdr.asp; nommain.asp; nom_NPT_add.inc; 
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nom_pathgrid_add.inc; nom_pathgrid_tbLinc; nom_PTH_add. inc; 

nom_PTH jjrid.inc; nomPTHtbl.inc; nomtop.asp; nomvalidate.inc; 

NomActCriteria.asp; NomActivity.asp; NomActivity.css; NomActvy.vbp; 

NomActvy.vbw; NomCriteriaScripts.asp; NomGISBData.vbp; 
5 NomParameters.cls; NomPath.cls; NomRpt.vbp; NomBpt.vbw; Noms.cls; 

NomTest.asp; nomtop.css; NPT_Routines.bas; NPT_updn.inc; NPTGridl.asp; 

NPTGridlhdr.asp; NPTGrid2.asp; NPTGrid2hdr.asp; NPTParameters.cls; 

NPTRoutines.bas; ns_mainpage.asp; nsdefault.asp; Parms.cls; partner02.asp; 

pathSelected.asp; PDAxls; pda _getinfo_utils.asp; pda_refresh_utils.asp; 
10 PDADetail.cls; PDAInterfaces.vbp; PDAL_PDQR.bas; PDALPDQR.cls; 

PDAObject.vbp; pdaqrOl.asp; pdaqrOl-styleposition.asp; pdaqr02.asp; 

pdaqnnain.asp; pdarOl.asp; pdarOl-styleposition.asp; pdar02.asp; 

pdarmain.asp; Pipeline.cls; pipelineChange.asp; pipelineChangeRefresh.asp; 

Pipelinelnfo.cls; PNT_Routines.bas; Point.cls; Points.cls; 
15 populateNomFrames.asp; populateNomGrids.asp; 

populateNomStatusCalendarNPT.asp; populateNomStatusCalendarPNT.asp; 

popidatePNTUGrids.asp; Preparer.cls; process.asp; 

ProcessOrdersbyModule.asp; PTH_Routines.bas; PTHGrid.asp; PTHhdr.asp; 

PubMod.bas; PubVars.bas; QuickResponse.cls; Rangeltem.cls; Rangeltems.cls; 
20 Receipent.cls; refreshCalendarNPT.asp; refreshCalendarPNT.asp; 

refreshlnformation.asp; refreshlnformation2.asp; refreshNPTFraines.asp; 

refreshPNTFrames.asp ; refreshPNTUFrames.asp; refreshViewCycle.asp; 

Report.vbg; RequestData.asp; RequestHeader.asp; Requests.asp; 

resizeScreen.asp; Results.cls; reviewgrid.asp; revnomOl.asp; revnom02.asp; 
25 revnommain.asp; rpt_ctr.asp; rept_ctr_bottom.asp; rpt_ctrJbottom2.asp; 

rept_ctr_bottom3.asp; rptctrmain .asp; rptjptnjbottom.asp; 

rptjptn_main.asp; rpt_qr_bottom.asp; rpt_qr_hdr.asp; rpt_status.asp; 

rpt_status_bottom.asp; ipt_status_hdr.asp; rpt_status_main.asp; rpt_utils.inc; 

RptFiIes.vbp; RptGISB.vbp; RptGMS.vbp; Sample.asp; saveNPTRecord.asp; 
30 savePNTPathRecord.asp; savePNTURecord.asp; SchQtyParam.cls; 

SchQtyParameters.cls; search.asp; SequenceGenerator.bas; sessionCheck.asp; 
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std jgetinfo_utils.asp; styledefinition.asp; submitNPTNoms.asp; Test.vbg; 
Testvbp; Test.vbw; TestConfirms.vbp; TestGBHelper.vbg; TestGBHelper.vbp; 
TestGBHelper.vbw; TestGISBStat.vbp; TestGISBStat.vbw; TestModule.bas; 
Tigger.cls; Timely.cls; TimelyGroup.cIs; timer.bas; Transactions.cls; 
5 TransType.cls; TransTypes.cls; trimString.asp; UDTJEdge.bas; 

UDT_Noms.bas; UDTJSchQty.bas; UDTDefinition.bas; UDTDefinitions.bas; 
updateDateFields.asp; UpdateNoms.cls; UpdateNoms.inc; 
updateNPTHeader.asp; updateNPTHeaderRequest .asp ; updn_stream.inc; 
updn_stream_add.inc; UPDNEntity.cls; upperConvert.asp; Userlnfo.cls; 
10 ValidatePath.cls; vahdation_uti!s.asp; Value.cls; vbsclient.inc; Vector, vbp; 
VectorZrows.cls; verify setup.asp; vol_rank.asp; vol_rank_NPT.asp; 
volLinks.inc; XMod.bas; zAppinfo.cls; zdb.bas; zDB.cls; zDBJRS.cls; and 
Zutility.bas. 

A computer implemented method of managing the delivery of products 

15 has been described that includes entering data relating to the delivery of the 
products using a user interface, interim storing some of the data in an 
intermediate database, submitting some of the data for processing by the 
system, and storing the submitted data in the intermediate database and a 
submitted database. In a preferred embodiment, the method further includes 

20 one or more of the following: (1) nominating the delivery of the products, and 
confirming the nominations; (2) allocating the delivery of the products, and 
confirming the allocations; (3) offering available delivery capacity for use, 
bidding on the available delivery capacity, and awarding the available delivery 
capacity; (4) generating system wide notices regarding the delivery of products; 

25 (5) generating system wide notices including operationally available and 
unsubscribed delivery capacity; (6) entering nomination data, retrieving 
corresponding nomination data, interim saving the nomination data, and 
submitting the nomination data for processing by the system; (7) entering 
nomination data, and retrieving corresponding nomination data; (8) entering 

30 predetermined allocation data, retrieving corresponding predetermined 

allocation data, interim saving the confirmed predetermined allocation data, 
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and submitting the confirmed predetermined allocation data for processing by 
the system; (9) entering predetermined allocation data, and retrieving 
corresponding predetermined allocation data; (10) entering confirmation data, 
and retrieving corresponding confirmation data; (11) entering predetermined 
5 allocation data, retrieving corresponding predetermined allocation data, interim 
saving the predetermined allocation data, and submitting the predetermined 
allocation data for processing by the system; (12) entering predetermined 
allocation data, and retrieving corresponding predetermined allocation data; 
(13) entering party information, and retrieving corresponding customer 

10 information for the party; (14) entering party information, and retrieving 
corresponding contract information for the party; (15) posting offers for 
available delivery capacity, posting bids for available delivery capacity, and 
awarding available delivery capacity; (16) entering system wide notice data, 
retrieving corresponding system wide notice data, interim saving the system 

15 wide notice data, and submitting the system wide notice data; (17) entering 
delivery capacity data, and retrieving corresponding operationally available and 
unsubscribed delivery capacity; and/or (18) permitting thin clients to nominate 
the delivery of products using pathed, non-pathed, and pathed non-threaded 
delivery model types. 

20 A system for managing the delivery of products has also been described 

that includes means for entering data relating to the delivery of the products 
using a user interface, means for interim storing some of the data in an 
intermediate database, means for submitting some of the data for processing by 
the system, and means for storing the submitted data in the intermediate 

25 database and a submitted database. In a preferred embodiment, the system 
further includes means for one or more of the following: (1) nominating the 
delivery of the products, and confirming the nominations; (2) allocating the 
delivery of the products, and confirming the allocations; (3) offering available 
delivery capacity for use, bidding on the available delivery capacity, and 

30 awarding the available delivery capacity; (4) generating system wide notices 
regarding the delivery of products; (5) generating system wide notices including 



H-224706.1 



-66- 



CA 02328595 2000-12-18 

Docket No. 21702.52.05 

operationally available and unsubscribed delivery capacity; (6) entering 
nomination data, retrieving corresponding nomination data, interim saving the 
nomination data, and submitting the nomination data for processing by the 
system; (7) entering nomination data, and retrieving corresponding nomination 
5 data; (8) entering predetermined allocation data, retrieving corresponding 
predetermined allocation data, interim saving the confirmed predetermined 
allocation data, and submitting the confirmed predetermined allocation data for 
processing by the system; (9) entering predetermined allocation data, and 
retrieving corresponding predetermined allocation data; (10) entering 

10 confirmation data, and retrieving corresponding confirmation data; (11) 
entering predetermined allocation data, retrieving corresponding 
predetermined allocation data, interim saving the predetermined allocation 
data, and submitting the predetermined allocation data for processing by the 
system; (12) entering predetermined allocation data, and retrieving 

15 corresponding predetermined allocation data; (13) entering party information, 
and retrieving corresponding customer information for the party; (14) entering 
party information, and retrieving corresponding contract information for the 
party; (15) posting offers for available delivery capacity, posting bids for 
available delivery capacity, and awarding available delivery capacity; (16) 

20 entering system wide notice data, retrieving corresponding system wide notice 
data, interim saving the system wide notice data, and submitting the system 
wide notice data; (17) entering delivery capacity data, and retrieving 
corresponding operationally available and unsubscribed delivery capacity; 
and/or (18) permitting thin clients to nominate the delivery of products using 

25 pathed, non-pathed, and pathed non-threaded delivery model types. 

A computer program for managing the delivery of products has also been 
described that includes instructions for entering data relating to the delivery of 
the products using a user interface, instructions for interim storing some of the 
data in an intermediate database, instructions for submitting some of the data 

30 for processing by the system, and instructions for storing the submitted data in 
the intermediate database and a submitted database. In a preferred 
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embodiment, the computer program further includes instructions for one or 

more of the following: (1) nominating the delivery of the products, and 

confirming the nominations; (2) allocating the delivery of the products, and 

confirming the allocations; (3) offering available delivery capacity for use, 
5 bidding on the available delivery capacity, and awarding the available delivery 

capacity; (4) generating system wide notices regarding the delivery of products; 

(5) generating system wide notices including operationally available and 

unsubscribed delivery capacity; (6) entering nomination data, retrieving 

corresponding nomination data, interim saving the nomination data, and 
10 submitting the nomination data for processing by the system; (7) entering 

nomination data, and retrieving corresponding nomination data; (8) entering 

predetermined allocation data, retrieving corresponding predetermined 

allocation data, interim saving the confirmed predetermined allocation data, 

and submitting the confirmed predetermined allocation data for processing by 
15 the system; (9) entering predetermined allocation data, and retrieving 

corresponding predetermined allocation data; (10) entering confirmation data, 

and retrieving corresponding confirmation data; (11) entering predetermined 

allocation data, retrieving corresponding predetermined allocation data, interim 

saving the predetermined allocation data, and submitting the predetermined ^ jpn 

20 allocation data for processing by the system; (12) entering predetermined 

allocation data, and retrieving corresponding predetermined allocation data; 

(13) entering party information, and retrieving corresponding customer 

information for the party; (14) entering party information, and retrieving 

corresponding contract information for the party; (15) posting offers for 
25 available delivery capacity, posting bids for available delivery capacity, and 

awarding available delivery capacity; (16) entering system wide notice data, 

retrieving corresponding system wide notice data, interim saving the system 

wide notice data, and submitting the system wide notice data; (17) entering 

delivery capacity data, and retrieving corresponding operationally available and 
30 unsubscribed delivery capacity; and/or (18) permitting thin clients to nominate 
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the delivery of products using pathed, non-pathed, and pathed non-threaded 
delivery model types. 

A system for managing the scheduling and delivery of products has also 
been described that includes an N-tiered database structure including interim 
5 stored and submitted scheduling and delivery data. In a preferred embodiment, 
the products include energy products. 

A computer program has also been described that includes instructions 
for providing an N-tiered database structure including interim stored and 
submitted scheduling and delivery data. In a preferred embodiment, the 
10 products include energy products. 

A system for managing the delivery of products has also been described 
that includes one or more thin clients adapted to enter data related to the 
delivery of the products, an intermediate database for storing interim saved 
data and submitted data related to the delivery of the products, a submitted 
15 database for storing submitted data related to the delivery of the products, and 
a host computer coupled to the thin clients, the intermediate database, and the 
submitted database adapted to process the submitted data. 

A computerized database for a system for managing the delivery of 
products has also been described that includes an intermediate database 
20 including interim stored data and submitted data, and a submitted database 
including the submitted data. 

A system for managing the delivery of products has also been described 
that includes one or more thin clients adapted to enter data related to the 
delivery of the products, means for storing interim saved data and submitted 
25 data, means for storing submitted data, and means for processing the submitted 
data. 

As will be recognized by persons of ordinary skill in the art having the 
benefit of the present disclosure, multiple variations and modifications can be 
made in the embodiments of the invention. Although certain illustrative 
30 embodiments of the invention have been shown and described, a wide range of 
modifications, changes, and substitutions is contemplated in the foregoing 
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disclosure. In some instances, some features of the present invention may be 
employed without a corresponding use of the other features. Accordingly, it is 
appropriate that the foregoing description be construed broadly and understood 
as being given by way of illustration and example only, the spirit and scope of 
the invention being limited only by the appended claims. 
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Claims 

What is Claimed Is: 



11. A computer implemented method of managing the delivery of products, 

2 comprising: 

3 entering data relating to the delivery of the products using a user 

4 interface; 

5 interim storing some of the data in an intermediate database; 

6 submitting some of the data for processing by the system; and 

7 storing the submitted data in the intermediate database and a submitted 

8 database. 

1 2. The method of claim 1, further comprising: 

2 nominating the delivery of the products; and 

3 confirming the nominations. 

1 3. The method of claim 1, further comprising: 

2 allocating the delivery of the products; and 

3 confirming the allocations. 

1 4. The method of claim 1, further comprising: 

2 offering available delivery capacity for use; 

3 bidding on the available delivery capacity; and 

4 awarding the available delivery capacity. 

1 5. The method of claim 1, further comprising: 

2 generating system wide notices regarding the delivery of products. 
1 6. The method of claim 1, further comprising: 
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2 generating system wide notices including operationally available and 

3 unsubscribed delivery capacity. 

1 7. The method of claim 1, further comprising: 

2 entering nomination data; 

3 retrieving corresponding nomination data; 

4 interim saving the nomination data; and 

5 submitting the nomination data for processing by the system. 

1 8. The method of claim 1, further comprising: 

2 entering nomination data; and 

3 retrieving corresponding nomination data. 

1 9. The method of claim 1, further comprising: 

2 entering predetermined allocation data; 

3 retrieving corresponding predetermined allocation data; 

4 interim saving the confirmed predetermined allocation data; and 

5 submitting the confirmed predetermined allocation data for processing 

6 by the system. 

1 10. The method of claim 1, further comprising: 

2 entering predetermined allocation data; and 

3 retrieving corresponding predetermined allocation data. 

1 11. The method of claim 1, further comprising: 

2 entering confirmation data; and 

3 retrieving corresponding confirmation data. 

1 12. The method of claim 1, further comprising: 

2 entering predetermined allocation data; 

3 retrieving corresponding predetermined allocation data; 
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4 interim saving the predetermined allocation data; and 

5 submitting the predetermined allocation data for processing by the 

6 system. 

1 13. The method of claim 1, further comprising: 

2 entering predetermined allocation data; and 

3 retrieving corresponding predetermined allocation data. 

1 14. The method of claim 1, further comprising: 

2 entering party information; and 

3 retrieving corresponding customer information for the parly. 

1 15. The method of claim 1, further comprising: 

2 entering party information; and 

3 retrieving corresponding contract information for the party. 

1 16. The method of claim 1, further comprising: 

2 posting offers for available delivery capacity; 

3 posting bids for available delivery capacity; and 

4 awarding available delivery capacity. 

1 17. The method of claim 1, further comprising: 

2 entering system wide notice data; 

3 retrieving corresponding system wide notice data; 

4 interim saving the system wide notice data; and 

5 submitting the system wide notice data. 

1 18. The method of claim 1, further comprising: 

2 entering delivery capacity data; and 

3 retrieving corresponding operationally available and unsubscribed 

4 delivery capacity. 
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1 19. The method of claim 1, further comprising: 

2 permitting thin clients to nominate the delivery of products using 

3 pathed, non-pathed, and pathed non-threaded delivery model 

4 types. 

1 20. A system for managing the delivery of products, comprising: 

2 means for entering data relating to the delivery of the products using a 

3 user interface; 

4 means for interim storing some of the data in an intermediate database; 

5 means for submitting some of the data for processing by the system; and 

6 means for storing the submitted data in the intermediate database and a 

7 submitted database. 

1 21. The system of claim 20, further comprising: 

2 means for nominating the delivery of the products; and 

3 means for confirming the nominations. 

1 22. The system of claim 20, further comprising: 

2 means for allocating the delivery of the products; and 

3 means for confirming the allocations. 

1 23. The system of claim 20, further comprising: 

2 means for offering available delivery capacity for use; 

3 means for bidding on the available delivery capacity; and 

4 means for awarding the available delivery capacity. 

1 24. The system of claim 20, further comprising: 

2 means for generating system wide notices regarding the delivery of 

3 products. 
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1 25. The system of claim 20, further comprising: 

2 means for generating system wide notices including operationally 

3 available and unsubscribed delivery capacity. 

1 26. The system of claim 20, further comprising: 

2 means for entering nomination data; 

3 means for retrieving corresponding nomination data; 

4 means for interim saving the nomination data; and 

5 means for submitting the nomination data for processing by the system. 

1 27. The system of claim 20, further comprising: 

2 means for entering nomination data; and 

3 means for retrieving corresponding nomination data. 

1 28. The system of claim 20, further comprising: 

2 means for entering predetermined allocation data; 

3 means for retrieving corresponding predetermined allocation data; 

4 means for interim saving the confirmed predetermined allocation data; 

5 and 

6 means for submitting the confirmed predetermined allocation data for 

7 processing by the system. 

1 29. The system of claim 20, further comprising: 

2 means for entering predetermined allocation data; and 

3 means for retrieving corresponding predetermined allocation data. 

1 30. The system of claim 20, further comprising: 

2 means for entering confirmation data; and 

3 means for retrieving corresponding confirmation data. 



1 31. The system of claim 20, further comprising: 



H-224706.1 



-75- 



CA 02328595 2000-12-18 

Docket No. 21702.52.05 



2 means for entering predetermined allocation data; 

3 means for retrieving corresponding predetermined allocation data; 

4 means for interim saving the predetermined allocation data; and 

5 means for submitting the predetermined allocation data for processing by 

6 the system. 

1 32. The system of claim 20, further comprising: 

2 means for entering predetermined allocation data; and 

3 means for retrieving corresponding predetermined allocation data. 

1 33. The system of claim 20, further comprising: 

2 means for entering party information; and 

3 means for retrieving corresponding customer information for the party. 

1 34. The system of claim 20, further comprising: 

2 means for entering party information; and 

3 means for retrieving corresponding contract information for the party. 

1 35. The system of claim 20, further comprising: 

2 means for posting offers for available delivery capacity; 

3 means for posting bids for available delivery capacity; and 

4 means for awarding available delivery capacity. 

1 36. The system of claim 20, further comprising: 

2 means for entering system wide notice data; 

3 means for retrieving corresponding system wide notice data; 

4 means for interim saving the system wide notice data; and 

5 means for submitting the system wide notice data. 

1 37. The system of claim 20, further comprising: 

2 means for entering delivery capacity data; and 
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3 means for retrieving corresponding operationally available and 

4 unsubscribed delivery capacity. 

1 38. The system of claim 20, further comprising: 

2 means for permitting thin clients to nominate the delivery of products 

3 using pathed, non-pathed, and pathed non-threaded delivery 

4 model types. 

1 39. A computer program for managing the delivery of products, comprising: 

2 instructions for entering data relating to the delivery of the products 

3 using a user interface; 

4 instructions for interim storing some of the data in an intermediate 

5 database; 

6 instructions for submitting some of the data for processing by the 

7 system; and 

8 instructions for storing the submitted data in the intermediate database 

9 and a submitted database. 

1 40. The computer program of claim 39, further comprising: 

2 instructions for nominating the delivery of the products; and 

3 instructions for confirming the nominations. 

1 41. The computer program of claim 39, further comprising: 

2 instructions for allocating the delivery of the products; and 

3 instructions for confirming the allocations. 

1 42. The computer program of claim 39, further comprising: 

2 instructions for offering available delivery capacity for use; 

3 instructions for bidding on the available delivery capacity; and 

4 instructions for awarding the available delivery capacity. 
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1 43. The computer program of claim 39, further comprising: 

2 instructions for generating system wide notices regarding the delivery of 

3 products. 

1 44. The computer program of claim 39, further comprising: 

2 instructions for generating system wide notices including operationally 

3 available and unsubscribed delivery capacity. 

1 45. The computer program of claim 39, further comprising: 

2 instructions for entering nomination data; 

3 instructions for retrieving corresponding nomination data; 

4 instructions for interim saving the nomination data; and 

5 instructions for submitting the nomination data for processing by the 

6 system. 

1 46. The computer program of claim 39, further comprising: 

2 instructions for entering nomination data; and 

3 instructions for retrieving corresponding nomination data. 

1 47. The computer program of claim 39, further comprising: 

2 instructions for entering predetermined allocation data; 

3 instructions for retrieving corresponding predetermined allocation data; 

4 instructions for interim saving the confirmed predetermined allocation 

5 data; and 

6 instructions for submitting the confirmed predetermined allocation data 

7 for processing by the system. 

1 48. The computer program of claim 39, further comprising: 

2 instructions for entering predetermined allocation data; and 

3 instructions for retrieving corresponding predetermined allocation data. 
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1 49. The computer program of claim 39, further comprising: 

2 instructions for entering confirmation data; and 

3 instructions for retrieving corresponding confirmation data. 

1 50. The computer program of claim 39, further comprising: 

2 instructions for entering predetermined allocation data; 

3 instructions for retrieving corresponding predetermined allocation data; 

4 instructions for interim saving the predetermined allocation data; and 

5 instructions for submitting the predetermined allocation data for 

6 processing by the system. 

1 51. The computer program of claim 39, further comprising: 

2 instructions for entering predetermined allocation data; and 

3 instructions for retrieving corresponding predetermined allocation data. 

1 52. The computer program of claim 39, further comprising: 

2 instructions for entering party information; and 

3 instructions for retrieving corresponding customer information for the 

4 party. 

1 53. The computer program of claim 39, further comprising: 

2 instructions for entering party information; and 

3 instructions for retrieving corresponding contract information for the 

4 party. 

1 54. The computer program of claim 39, further comprising: 

2 instructions for posting offers for available delivery capacity; 

3 instructions for posting bids for available delivery capacity; and 

4 instructions for awarding available delivery capacity. 
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1 55. The computer program of claim 39, further comprising: 

2 instructions for entering system wide notice data; 

3 instructions for retrieving corresponding system wide notice data; 

4 instructions for interim saving the system wide notice data; and 

5 instructions for submitting the system wide notice data. 

1 56. The computer program of claim 39, further comprising: 

2 instructions for entering delivery capacity data; and 

3 instructions for retrieving corresponding operationally available and 

4 unsubscribed delivery capacity. 

1 57. The computer program of claim 39, further comprising: 

2 instructions for permitting thin clients to nominate the delivery of 

3 products using pathed, non-pathed, and pathed non-threaded 

4 delivery model types. 

1 58. A computer implemented method for managing the scheduling and 

2 delivery of products, comprising: 

3 providing an N-tiered database structure including interim stored and 

4 submitted scheduling and delivery data. 

1 59. The method of claim 58, wherein the products include energy products. 

2 60. A system for managing the scheduling and delivery of products, 

3 comprising: 

t an N-tiered database structure including interim stored and submitted 

5 scheduling and delivery data. 

L 61. The system of claim 60, wherein the products include energy products. 

62. A computer program, including: 
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2 instructions for providing an N-tiered database structure including 

3 interim stored and submitted scheduling and delivery data. 

1 63. The computer program of claim 62, wherein the products include energy 

2 products. 

1 64. A system for managing the delivery of products, comprising: 

2 one or more thin clients adapted to enter data related to the delivery of 

3 the products; 

4 an intermediate database for storing interim saved data and submitted 

5 data related to the delivery of the products; 

6 a submitted database for storing submitted data related to the delivery of 

7 the products; and 

8 a host computer coupled to the thin clients, the intermediate database, 

9 and the submitted database adapted to process the submitted data. 

1 65. A computerized database for a system for managing the delivery of 

2 products, comprising: 

3 an intermediate database including interim stored data and submitted 

4 data; and 

5 a submitted database including the submitted data. 

1 66. A system for managing the delivery of products, comprising: 

2 means for permitting one or more thin clients adapted to enter data 

3 related to the delivery of the products; 

4 means for storing interim saved data and submitted data; 

5 means for storing submitted data; and 

6 means for processing the submitted data. 
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